The automation worked for eight months. Then a customer called to ask why they never got their confirmation, and you discovered that none of them had, for three weeks. Nothing alerted you. The platform’s dashboard, which nobody looks at, had a small red number on it the whole time. The thing you built to stop dropping balls dropped every ball, quietly, and charged you a subscription for it.
This article is about automation error handling: why workflows break, and the practices that make them fail loudly instead of silently, recover on their own from temporary failures, and hand the rest to a person with enough information to fix them. None of it is complicated. All of it is skipped, because when you build an automation you are thinking about the happy path.
Our view, from building and repairing these for businesses, is that reliability is not a property of the platform. Zapier, Make, and n8n are all reliable. Reliability is a set of habits.
What breaking actually means
An automation is a chain of steps across several systems: your form tool, your CRM, your accounting software, an email service, maybe a language model. Every step is a request to another system, and every request can fail. The other system can be down, slow, or reject the request because a password expired. It can return something in a different shape than last week because the vendor shipped an update. Your own data can be odd: a name with a quote mark, an order with zero lines.
The ordinary-business analogy is a courier route. The van breaks down (a system is down). A road is closed (a request times out). The recipient’s address changed and nobody told you (the vendor changed their API). The package was delivered twice because the first attempt was recorded as failed when it had succeeded (a retry created a duplicate). A good courier company has a process for each. A bad one finds out from the customer.
1. Retry the temporary failures, with a pause and a limit
A large share of failures are transient: a service is briefly unavailable, a request times out, a rate limit (the cap a service places on requests per minute) is hit. The right response is to wait and try again. Every serious platform supports this per step: n8n has retry settings on each node, Make has error handlers with a retry directive, Zapier auto-replays some failures on higher plans.
The rules: wait before retrying, and wait longer each time (a few seconds, then thirty, then a few minutes). Cap the attempts at three to five, then treat the failure as real. Retrying instantly and forever is how a small outage at a vendor turns into thousands of hammering requests that get your account blocked. And only retry steps that are safe to repeat, which brings us to the practice most failures come from.
2. Make every step idempotent, so running it twice is harmless
Idempotent is a technical word for a simple idea: doing something twice has the same result as doing it once. Marking an invoice as paid is idempotent (it is paid either way). Adding a payment to an invoice is not (add it twice and the customer is over-credited). Sending a welcome email is not either.
Why it matters: retries, duplicate triggers, and double-clicks all cause a step to run more than once. Without idempotency you get two customers, two invoices, two texts at 6am. The fix is a check before every create or send: look the customer up first and update if found; check whether an email was already sent for this order ID. Many services support an idempotency key (a unique reference sent with the request so the service ignores repeats); use it where it exists. This is the practice that turns retry from dangerous to safe.
3. Give every failure somewhere to go: the dead-letter queue
A dead-letter queue is the pile of items that failed after retries and could not be processed. The name comes from the post office’s dead letter office, where undeliverable mail goes so a person can deal with it. Without one, a failed item is simply gone: the lead that could not be filed, the invoice that could not be created, lost.
The implementation is modest: a sheet, a table, or a dedicated workflow that receives the failed item with its data, the step that failed, the error, and the time. A person looks at the pile daily; most items can be fixed and re-run in a minute. On n8n this is the error workflow pattern; on Make an error route writing to a data store; on Zapier the failed-run list plus a workflow that copies failures somewhere visible. The test: break a workflow deliberately, send an item through, and ask where it is now. If the answer is nowhere, there is no dead-letter queue.
4. Alert a person the same hour, not the same month
A failure nobody knows about is the whole problem. Every automation that matters has an alert: when an item lands in the dead-letter queue, when a workflow fails repeatedly in an hour, when a scheduled workflow does not run at all, a message goes to a named person by a channel they actually see, not a shared address nobody owns.
Two kinds of alert are worth distinguishing. The failure alert says something broke. The silence alert says something did not happen: the Monday report did not send, no leads arrived on a day when there are always leads. Silence alerts catch the failures that throw no error, like a trigger that quietly stopped firing, and they are almost never built. Keep alerts rare enough to be read; one that fires daily gets muted, so fix the workflow instead.
5. Log what went in, what happened, and what came out
When something goes wrong, the question is always “what did it see and what did it do?” A log answers it. For every run: the trigger data, what was sent to each external system, what came back, and the result. The platforms keep execution logs, and for a while they are enough. For anything touching money or customers, also write a one-line record per run to a place you control.
If a language model is in the chain, log the exact text it was given and returned, every time; “the AI decided” is not an explanation anyone can act on. Prune logs full of customer data after weeks, not years, and keep any log that leaves the platform under the same access controls as its source.
6. Plan for the “one thing changed upstream” failure
The failure that ends most automations is not a crash. It is a small change at the source. The form tool renames a field. The CRM changes the shape of the data it returns. A colleague edits a spreadsheet column header. A connection’s token expires. Nothing explodes; the workflow keeps running and quietly produces wrong output, or stops triggering, and nobody is told.
Three defences. Validate inputs at the start of every workflow: check that the fields you depend on are present and in the expected shape, and route anything that is not to the dead-letter queue. Prefer stable identifiers to labels (a field’s ID rather than its display name). And track connection expiry: most platforms show when an account needs re-authorising, and a calendar reminder a week ahead is cheaper than the outage.
7. Build failure paths into AI steps specifically
A language model step (software that reads text and writes text back, used to classify, extract, or draft) fails differently. It rarely errors. It returns an answer in the wrong shape, or a value that is not one of the allowed ones, or a confident answer to a question it should have declined. Error handling for AI steps is mostly output checking.
Every AI step returns in a fixed structure. The next step checks that structure and the allowed values, and anything that fails, carries low confidence, or was marked unclear goes to a person rather than onward. The model is never wired directly to a send, a charge, or a delete. Treat its answer as a suggestion from a fast, well-read, occasionally wrong colleague. If the provider is down, retry with a pause, then route to a human. Where these steps earn their place is the subject of 25 AI Workflow Automation Examples for a Real Business.
8. Keep workflows small, documented, and reviewed monthly
A forty-step workflow fails in forty ways and is understood by one person. Small workflows chained together fail in isolation. Each has one job, a name that says what triggers it and what it does, and a note with who depends on it and what to do if it stops, with exports kept in a folder the business owns. The platform habits are in Make.com Automation Guide for Business Owners Who Want It to Last and Self-Host n8n for Your Business Without Being Held Hostage, and the trade-offs in n8n vs Make vs Zapier for a Business Without a Developer.
Once a month, someone spends an hour on three things. The dead-letter queue: what failed and whether the same cause keeps appearing (a repeat cause is a bug to fix, not a pile to clear). The alerts: which fired and whether they were real. The runs: any workflow whose volume changed, and any that has not run at all, which usually means its trigger died. Write five lines in a shared doc. This review is what turns a pile of workflows into a managed system.
Picture a business like this one
The business below is a composite of the kind of company that writes to us, not a client. The numbers describe the shape of the problem, not a case study.
Picture a business like this one: a mid-sized property management company with about 50 staff and a few thousand units. Over three years they built some 25 workflows on a mix of Zapier and Make: maintenance requests from the tenant portal to the work order system, vendor invoices to accounting, lease renewals to email sequences, rent reminders by text. They are useful and nobody understands all of them.
What is wrong: last quarter the tenant portal changed a field name and the maintenance workflow silently created work orders with no unit number for eleven days. A vendor invoice workflow double-posted 30 invoices after a retry storm during an accounting outage. And the rent reminder for one building stopped triggering after a connection was re-authorised, and nobody noticed until tenants asked.
What a company like this would build:
- An inventory of all 25 workflows on one page: trigger, steps, owner, dependent process. Four are retired.
- Input validation at the top of every workflow, routing any item missing a required field to a dead-letter sheet with the reason.
- Idempotency checks before every create in the accounting and work-order systems, keyed on the invoice number and the request ID.
- Retries with backoff on every external step, capped at four attempts.
- One dead-letter workflow across both platforms that writes failures to a single sheet and messages the operations lead.
- Silence alerts on the six scheduled workflows and on each building’s rent reminder.
- Logging of every AI classification with input and output, and the monthly review on the operations lead’s calendar.
What changes: the next upstream change is caught the same morning by the validation step and the dead-letter alert. Retries become safe. A silent rent reminder triggers a silence alert within a day. The operations lead spends an hour a month instead of a week a quarter, and the owner stops hearing about failures from tenants.
What it costs to run
Almost nothing beyond what you already pay. Retries, error routes, data stores, and logs are features of the platform you have. A dead-letter sheet is free. An uptime or silence monitor is a free tier on several services or a scheduled workflow. Alerts by text cost cents.
The real cost is time: an hour or two per workflow to add the error handling properly when it is built (much less than adding it after a failure), and an hour a month for the review. Businesses that skip both spend far more on the one incident that finally gets noticed.
The mistakes we see most
- No alert anywhere. The failure count on the dashboard is the only signal, and nobody looks at it.
- Retries without idempotency. An outage becomes a duplicate-posting incident.
- AI output used unchecked. The model’s wrong-shaped answer flows straight into a customer-facing step.
- Nobody reviews. Twenty-five workflows, no inventory, no owner, and the builder has left; one of the ten in AI Mistakes Businesses Make, the Ten Ways Money Gets Wasted.
When to bring in help
An owner or office manager can do most of this alone on any platform: add retries, add an error route that writes to a sheet and sends a text, look up before you create, and put a monthly hour on the calendar. Those four habits prevent most of the failures described here.
A developer is worth bringing in for an audit of an existing tangle (an afternoon that usually finds two or three silent failures already in progress), for anything touching money where idempotency must be done correctly, for AI steps that need output checking, and for the monitoring layer most owners do not have time to build.
Levelbrook builds and repairs automation like this for businesses, on a fixed price from a written scope, with everything running in accounts and servers you own and a runbook handed over at the end. If you have automations you are not sure are running, the form below is a good place to ask.