The day an automation goes live, it works. The tests passed, the client watched it run, the invoices flowed into Xero on their own. Then, some Tuesday three months later, it stops working — and the uncomfortable part is that nobody notices for a while. The invoices stop flowing, but the inbox still looks normal because they were never arriving anywhere visible. A person eventually asks where a payment is, someone digs, and the team discovers the workflow has been failing silently for eleven days. Trust in "the automation stuff" drops to zero overnight, and the next improvement project gets a much harder reception.
This pattern is not rare. It is the default outcome for automations that are built, celebrated, and never looked at again. Automations are software, and software decays: the world around it changes while it stays the same. The businesses that get durable value from automation are not the ones that build the cleverest workflows. They are the ones that treat monitoring, maintenance, and ownership as part of the build, not as an afterthought.
Why automations decay quietly
Manual processes fail loudly. When the person who sends invoices is sick, invoices visibly do not go out and someone covers. Automated processes fail silently because the failure mode is an absence: nothing happens, and nothing happening looks exactly like nothing needing to happen. There is no pile of paper growing on a desk. The queue is invisible.
The triggers of decay are mundane:
- An API changes. Xero, Shopify, Airtable, and every other platform ship updates. Most are backwards compatible; occasionally one renames a field, deprecates an endpoint, or changes a default behaviour, and the workflow that depended on it breaks.
- Someone renames a field in Airtable because "Status (new)" seemed clearer at the time. Every automation referencing "Status" now writes to nowhere or fails outright.
- An auth token expires. The person who connected the accounts used their own login; they change their password or leave the company, and every connected scenario loses access at once.
- Volume grows past the design assumption. The workflow built for 30 orders a day now sees 300 on a promotion day, hits rate limits or a plan's operation cap, and drops half of them.
- An edge case arrives that nobody designed for: a customer with no email address, an invoice in a foreign currency, a refund instead of a payment. The workflow errors, or worse, guesses.
None of these are exotic. All of them will happen to you if you run automations for long enough. The question is whether you find out in minutes or in weeks.
The failure modes we see most
In audits of existing automation estates — often built by a founder, a departed ops person, or a previous vendor — the same handful of failures account for most of the damage.
Silent failures. The workflow errors and the only notification goes to an email address nobody reads, or nowhere at all. Zapier, Make, and n8n all have error alerting; in our experience fewer than half of self-built setups have it switched on and pointed at a monitored destination. This is the single most common and most fixable problem.
Auth token expiry. Connections die quietly and the workflow either errors or, worse, keeps "running" while doing nothing. The fix is procedural as much as technical: connect accounts with service credentials where the platform allows it, document where each connection lives, and alert on connection health, not just run errors.
Schema drift. Airtable is the usual victim because it is deliberately easy to edit. A renamed field, a deleted select option, a changed field type — each is a small, reasonable human act that breaks an automation that assumed the old shape. Treat the base schema as an API contract: changes go through the owner, and the owner knows which workflows depend on which fields.
Edge cases at volume. A workflow that handles 95 percent of cases is charming at ten items a day and a part-time job at two hundred. Volume exposes the long tail. This is why we design exception queues from day one rather than bolting them on after the first bad month.
Orphaned automations. The person who built the workflows leaves. Their Zapier account is deactivated, or their Make scenarios keep running but nobody knows what they do, and the team's relationship with automation becomes superstition: do not touch anything, because nobody knows what it does. We have audited businesses running forty-plus scenarios where staff could explain fewer than ten.
The ownership problem
Every automation needs a named owner. Not a team, not "ops," not "IT" — a person whose name is written next to the workflow in the register.
The owner does not have to be technical. They are the person who gets the alert, who knows what the workflow is supposed to do, who notices when the output looks wrong, and who is empowered to say "this needs fixing" and to whom. In most SMBs we work with, the owner is the operations manager or the team lead closest to the process. The technical fixing can be done by a contractor, a vendor, or us — but the accountability cannot be outsourced, because the person who feels the pain of a failure is the only one reliably motivated to catch it early.
Ownership also solves the offboarding problem. When someone leaves, part of the handover checklist is the automation register: every workflow they owned gets reassigned, every connection authenticated with their credentials gets re-connected. Fifteen minutes of register maintenance prevents the orphaned-automation estate entirely.
Monitoring patterns that catch failure fast
You do not need observability platforms. Three simple patterns catch the large majority of failures, and all three can be built with the same tools the automations run on.
Error alerts, routed to a human. Every workflow platform can send a notification on failure. Point it somewhere alive: a shared Slack or Teams channel, a monitored inbox, an Airtable "incidents" table that someone checks daily. Include the workflow name, the time, a record ID, and a redacted error message — not the raw workflow input, which often contains customer or financial data that does not belong in a shared channel. When an investigation genuinely needs the full payload, store it in a restricted incident record with limited access, and let the alert point to it. "Scenario X failed" is not actionable; "Xero bill creation failed for supplier Y, invoice 1042, error: duplicate invoice number" is.
Heartbeat checks. Error alerts catch workflows that run and fail. They do not catch workflows that never ran at all — the trigger broke, the webhook stopped arriving, the schedule was paused. For anything that should run on a cadence, add a heartbeat: the workflow writes a timestamp to a log table on every successful run, and a separate daily check flags any workflow whose last success is older than expected. If the daily invoice sync did not run by 9am, someone hears about it at 9:05, not at month-end.
Reconciliation reports. The strongest pattern, and the least common. Compare totals between systems that should agree: the number and value of orders in Shopify this week versus invoices created in Xero; documents received in the intake mailbox versus records created in Airtable; payments received versus payments matched. Reconciliation catches the class of failure that alerts and heartbeats miss — the workflow that runs "successfully" but processes the wrong thing, the duplicate, the gap. A weekly reconciliation that takes a person twenty minutes to review is the difference between confidence and hope.
Documentation someone else can pick up
Documentation for automations does not need to be long. It needs to exist, be findable, and answer five questions for every workflow:
- What does this do, in one sentence, in business language?
- What triggers it, and what systems does it touch?
- What does "working correctly" look like — the output you would check?
- Where do failures surface, and who gets told?
- Who owns it?
A single Airtable table — an automation register — covers this and doubles as the ownership tracker and the heartbeat log's companion. Add a link from each register entry to the scenario itself, and a new team member or an external consultant can orient themselves in an afternoon instead of reverse-engineering for a week. We build this register as a deliverable on every engagement, because the engagement is not done when the workflow runs; it is done when the client can keep it running.
When to repair, when to rebuild
Not every failure deserves a fix. Sometimes the right call is to retire or rebuild, and the decision framework is straightforward.
Repair when the workflow still matches the process and the failure is mechanical: a broken connection, a renamed field, an expired token. These are minutes-to-hours fixes.
Rebuild when the process has changed underneath the workflow — the business now sells through two channels instead of one, the pricing model changed, the team structure changed — and the automation has been patched twice already to keep up. A workflow with three layers of workaround costs more to maintain than to replace, and each patch raises the chance of the silent, subtle failures that reconciliation is supposed to catch. Retire entirely when the volume no longer justifies it; an automation that saves ten minutes a month but needs quarterly attention is a liability, and deleting it is a service to the business.
A useful rule from our audits: if the person explaining the workflow uses the phrase "it's a bit hacky" more than once, put it on the rebuild list.
A monthly maintenance checklist
This is the checklist we hand to clients at the end of an engagement. It takes one person roughly an hour a month for a typical SMB estate of fifteen to thirty workflows.
- Review the error log and incident channel. Every failure this month either fixed, scheduled for fixing, or consciously accepted.
- Check heartbeat ages. Every scheduled workflow ran within its expected window.
- Review the reconciliation report for the past month and explain every variance.
- Skim the exception queues. Are the same exceptions recurring? Recurring exceptions are design feedback, not bad luck — fix the rule or the extraction, not the item.
- Spot-check outputs. Open five recent items the automations produced — bills in Xero, records in Airtable — and verify them against their sources.
- Review the register. Ownership current, documentation current, any workflow nobody can explain flagged for rebuild or retirement.
- Check connection health: any warnings from the platforms, any credentials approaching expiry, any connected account belonging to someone who has left or changed roles.
- Note plan usage. Approaching an operations cap on Zapier or Make is a predictable, avoidable outage — see it coming in the numbers, not in the failure.
Where to start
If you already have automations running, start with the register: list every workflow you can find, assign each an owner, and switch on error alerts for all of them this week. That single afternoon closes the most common failure mode we find. Then add heartbeats to anything that runs daily, and a weekly reconciliation on your highest-value flow — usually the one that ends in money.
If you suspect your automation estate has quietly drifted — scenarios nobody can explain, outputs nobody fully trusts — book a 30-minute audit and we will walk through it with you: what is running, what is broken, what is worth repairing, and what it would take to make the whole thing dependable again.