Most Automations Do Not Crash. They Quietly Stop Doing Their Job.
Quick verdict: the automation that fails loudly is the easy one, because you get an error email. The costly failures are silent: a workflow that still runs but skips half its inputs, or an AI step whose output slowly changed shape. A named owner and a 15-minute check once a month catch most of them.
This guide is part of our AI Automation for Small Business series.
The 7 Failure Modes
| # | Failure mode | Loud or silent | First sign |
|---|---|---|---|
| 1 | Expired connection | Loud | Authentication errors in run history |
| 2 | Changed field or form | Often silent | Blank values in the output |
| 3 | Unexpected input | Mixed | Occasional errors, or odd records |
| 4 | Rate limits and outages | Loud | Bursts of errors at busy times |
| 5 | AI output drift | Silent | Later steps receive text in the wrong shape |
| 6 | Usage limit reached | Loud, but easy to miss | Runs held or paused near month end |
| 7 | Nobody owns it | Silent | The person who built it has left |
1. Expired connection
Every automation logs in to your apps on your behalf. Password changes, security policy updates, or a revoked permission break that login. The run fails with an authentication error. The fix is to reconnect the account, and the prevention is to connect apps with a shared service account, not an individual’s personal login.
2. Changed field or form
Someone renames a form question, adds a required CRM field, or reorders spreadsheet columns. The automation still runs, but a mapped field now arrives empty. Nothing errors. You find out when a client receives “Hi ,” with no name. Prevention: add a filter that stops the run when an essential field is blank, and tell the team that forms and columns feeding an automation are not to be edited without the owner knowing.
3. Unexpected input
The workflow was tested with tidy data. Real data includes a phone number with letters in it, a 4,000-word email, an attachment where text was expected, or two submissions one second apart. Prevention: test with your five messiest real examples, not with sample data.
4. Rate limits and outages
Apps limit how many requests they accept per minute, and every service has occasional downtime. A burst of activity, such as an import of 500 contacts, can trip the limit. Prevention: use the platform’s retry feature and avoid triggering bulk changes during working hours.
5. AI output drift
An AI step does not return the same text every time, and model updates change behaviour. A prompt that returned clean JSON for three months may one day wrap it in a sentence, add a field, or change a category name from “refund_request” to “Refund”. The next step, which expected the old shape, either fails or misroutes. Prevention: ask for structured output, list the allowed values in the prompt, and add a fallback route for anything that does not match. Our Zapier AI lead follow-up guide shows the review step that catches bad drafts before they send.
6. Usage limit reached
Zapier sells tasks, Make sells credits, and n8n Cloud sells executions, all per month. When you run out, runs are held, paused, or billed at a higher rate depending on the platform and plan. This tends to happen in the last week of the month, when nobody is watching. Prevention: check usage mid-month and set the platform’s usage alerts.
7. Nobody owns it
The most common cause of long-running silent failure is organisational. The person who built the workflow left or changed roles, the workflow lives in their personal account, and nobody else knows it exists until something downstream stops. Prevention: one named owner per workflow, a one-paragraph description stored with it, and business-owned accounts. Our governance policy template includes an ownership line for this.
What Each Platform Gives You
| Zapier | Make | n8n | |
|---|---|---|---|
| Where to see failures | Zap history | Scenario history and incomplete executions | Executions list |
| Automatic retry | Autoreplay, on Professional plans and higher | Break error handler stores and retries a failed run | Retry settings on individual nodes |
| Custom handling | Error handler on a step, which runs an alternative path | Five handlers: Break, Commit, Ignore, Resume, Rollback | A separate error workflow started by the Error Trigger node |
| Behaviour to know | A Zap turns itself off if 95% of its runs error over 7 days. Adding an error handler turns autoreplay off for that Zap, and Zapier sends no error email when a handler runs. | Ignore and Commit mark the run as a success, so use them only where a skipped item truly does not matter. | The error workflow only runs for workflows that are active, not for manual test runs. |
Sources: Zapier: set up custom error handling, Zapier: replay Zap runs, Make: error handlers, n8n: Error Trigger node.
One point in that table deserves repeating. On Zapier, an error handler suppresses the error email. If your handler does nothing visible, you have converted a loud failure into a silent one. Every error path should end by telling a person: a Slack message, an email, or a row in an error log.
The 15-Minute Monthly Check
Put a recurring 15-minute slot in the owner’s calendar. For each live workflow:
- Open the run history and filter to errors for the last 30 days. Any at all? Read the most recent one. (3 minutes)
- Compare run count to reality. If the form had 40 submissions and the workflow ran 26 times, something is being skipped. This is the check that finds silent failures. (3 minutes)
- Open one recent successful run and read what each step actually produced. Look for blank fields and odd AI output. (3 minutes)
- Check usage against the plan limit and whether you are on course to exceed it. (2 minutes)
- Check connections for any that show a warning or need reconnecting. (2 minutes)
- Ask whether the workflow is still needed. Turn off anything that no longer serves a live process. (2 minutes)
Record the date and one line of findings in a shared log. A check that is not written down tends to stop happening.
Build Habits That Prevent Most Breaks
- Guard essential fields. Stop the run when a required value is blank.
- Give every router or path a default branch that alerts a person.
- End every error path with a notification.
- Name workflows by what they do, such as “New lead to CRM and follow-up draft”, not “Zap 14”.
- Write one paragraph of documentation per workflow: trigger, what it does, who owns it, what to do if it fails.
- Use business-owned accounts for every connection.
- Keep the workflow count small. Five maintained workflows are worth more than twenty forgotten ones.
FAQ
How often do automations need maintenance?
A short monthly check is enough for most small-business workflows. Check sooner after you change a connected form, CRM field, or prompt.
Will the platform tell me when something breaks?
For loud failures, usually yes, by email. For silent ones, no. A run that completes with a blank field is a success as far as the platform can tell.
Should I add error handlers to every step?
No. Add them to the steps most likely to fail, typically AI calls and third-party apps with rate limits, and make sure each handler notifies someone.
What is the single most useful check?
Comparing how many times the workflow ran with how many times it should have run.
Does switching platform fix reliability problems?
Rarely. Most failures here come from inputs, ownership, and design, which move with you. See Zapier vs Make vs n8n for when a move is justified.
Final Recommendation
Assign an owner to every workflow today and book the first 15-minute check. If you can only do one thing from this guide, do the run-count comparison each month. It is the check that finds the failures nobody reported.
