Why automations fail quietly
Automations depend on things outside your control. Common causes of silent failure:
- Disconnected accounts. A password change, expired token or removed user disconnects an integration.
- Changed fields. Someone renames a form field or CRM property, and the mapping breaks or sends blanks.
- Filters that stop matching. A new form option isn't covered by a filter, so those submissions are skipped without error.
- Limits. Plan limits, API rate limits or task quotas are reached and runs pause.
- Upstream changes. An app changes how its trigger works.
Only some of these produce an error. Filters and blank fields often "succeed" while doing the wrong thing.
Layer 1: error alerts
Every connector platform has some error notification — for example, Zapier's error troubleshooting and n8n's error workflows. Configure them to reach a named person, not just the account owner's inbox, and make sure the alert says which workflow failed and on what record.
Layer 2: heartbeat checks
Errors only catch runs that start. A heartbeat checks that runs are happening at all. Simple versions:
- A scheduled check that counts yesterday's runs of a critical workflow and alerts if it's zero.
- Comparing counts: form submissions received versus CRM records created. A gap is a signal.
- Sending a test submission on a schedule and checking it arrives — clearly labelled as a test and excluded from reports.
Layer 3: a weekly human review
Ten minutes a week is enough for most small setups:
- Check run history for each customer-facing workflow. Any unusual drop or spike?
- Look for runs that "succeeded" with empty or default values.
- Confirm connected accounts are still connected.
- Check plan usage against limits.
- Review any items in a failed or held queue.
Make failures recoverable
Detection is half the job. The other half is being able to fix what was missed:
- Keep the source of truth. If the form also emails a copy to a shared inbox, missed records can be recovered.
- Use replay features where the platform offers them, after fixing the cause.
- Avoid double actions when replaying — check whether the customer already received something before resending; duplicate handling applies here too.
- Tell affected customers if a promised message never went out and it matters.
Record it
For each workflow, the runbook should say who receives alerts, what the heartbeat check is, and how to pause the workflow safely. When a failure happens, add a line about the cause and fix — patterns become obvious after a few entries.
Questions
Who should receive failure alerts?
A named person who can act on them, plus a backup. Alerts sent to a shared inbox nobody owns are the same as no alerts.
How often should I check automations?
Alerts should reach someone immediately for anything customer-facing. On top of that, a short weekly review of run history catches the quieter problems.
Sources and further reading
- error troubleshooting help.zapier.com
- error workflows docs.n8n.io
Official documentation changes. Check the current version before you rely on a rule, limit or setting.
Next step
Start with one workflow worth fixing.
Bring the real steps, the tools you already use and the place the handoff gets stuck. We review feasibility, access and approval points before quoting — no instant integration promise.
See Business Automations for what we scope, or prepare a custom quote brief.