Every automation will break. That's not pessimism — it's just what happens when your workflow depends on services you don't control changing on schedules you don't see.
The question isn't whether. It's how long until you find out, and that's entirely a design decision you make when you build it.
A workflow that fails loudly costs you an hour. The same workflow failing quietly can cost you a quarter of leads before anyone notices the enquiry form stopped feeding the CRM in March.
The short version
Build these four things in:
- Alerting — you find out within hours, not weeks
- A dead-letter path — failed items go somewhere retrievable, never nowhere
- Sensible retries — for transient failures, with limits
- A heartbeat check — detects the failure mode alerting can't
The principle: design for detection, not just for success. A workflow you can't tell is broken is a workflow you should assume is broken.
What a silent failure is
The failure mode that costs the most, and the one people don't design against.
A loud failure throws an error. The platform logs it, marks the run as failed, and — if you've set it up — tells you.
A silent failure completes successfully while doing nothing useful.
The common shapes:
The trigger stops firing. Your form plugin updates and changes its webhook. The workflow never runs, so it never errors. Zero runs is not an error condition — it looks exactly like a quiet week.
A field is renamed. The workflow still runs, writes an empty value into the field it expected data in, and reports success. Your CRM fills with records missing the one field that mattered.
A filter starts rejecting everything. A condition that used to pass now doesn't, because the incoming data shape changed slightly. Every run "completes" by correctly deciding to do nothing.
Authentication expires mid-chain. Step one works, step three fails silently, and depending on the platform, the run may still report as successful.
What unites them: nothing errors. Your dashboard is green. And you find out when a customer asks why nobody called them back.
Build 1 — Alerting you'll actually notice
Turn on your platform's built-in error notifications. Every major platform has them, and they're frequently off by default or routed to an address nobody reads.
Send alerts somewhere you look. Email works if you read that inbox. Slack or a mobile push is better. An alert going to a shared inbox nobody monitors is the same as no alert.
Make them specific. "Workflow failed" is barely useful. "Form-to-CRM workflow failed at step 3: authentication error" tells you what to do.
Set an escalation for repeats. One failure might be a transient API hiccup. The same workflow failing five times in an hour is a real problem and deserves a louder signal.
And separate alerts from noise. If your automation alerts land in the same channel as everything else, they'll be scrolled past. A dedicated channel that's normally silent is a channel you'll notice.
Build 2 — A dead-letter path
The single most valuable pattern here, and the one people skip.
When a step fails, the data has to go somewhere retrievable — never nowhere.
How it works: add an error branch that catches failures and writes the incoming data to a fallback destination. A spreadsheet, a database table, a dedicated email address, a Slack channel.
Why it matters enormously: when the workflow breaks, the leads keep arriving. Without a fallback, they're gone — the form submitted, the workflow failed, and there's no record anywhere. With one, you have a list of exactly what to reprocess once you've fixed it.
A worked example. Form submission → CRM. If the CRM step fails, the error branch appends the submission to a Google Sheet and posts to Slack. You fix the authentication that afternoon, open the sheet, and import the eleven submissions that arrived meanwhile.
Without that branch, those eleven people submitted a form, saw "thank you," and vanished.
Where this matters most: anything carrying leads, orders, or customer data. Anything where the input can't be regenerated.
Build 3 — Retries, with limits
Some failures are transient — a service was briefly down, a request timed out, a rate limit was hit. Retrying fixes those without any human involvement.
Retry for: timeouts, 5xx server errors, rate limits, temporary connection failures.
Don't retry for: authentication failures, missing required fields, malformed data, 4xx errors. Nothing about waiting makes a wrong API key correct, and retrying just burns your task allowance while masking the real error.
Use exponential backoff where the platform supports it — wait a little, then longer, then longer still. Immediate hammering makes a struggling service worse.
Cap the attempts. Three to five, then fail properly into the dead-letter path. Infinite retries turn a visible failure into a silent one, which is the opposite of what you want.
Watch for duplicates. If a step succeeded but the confirmation was lost, a retry can create a second record. Use idempotency keys where your tools support them.
Build 4 — A heartbeat check
The one that catches silent failures, and almost nobody builds it.
The problem: alerting only fires on errors. A workflow that stops being triggered never errors, so alerting never fires.
The solution: a separate check that watches for absence.
How to build one: a scheduled workflow that runs daily and asks "did the main workflow run at least N times in the last 24 hours?" If not, alert.
Where to get the data: most platforms expose run history via API. Alternatively, have your main workflow write a timestamp somewhere on each successful run, and have the heartbeat check how old the most recent one is.
A cruder version that still works: submit your own contact form once a week and confirm the whole chain completed. Two minutes, and it tests the actual path a real user takes rather than what your dashboard claims.
This is the check that would have caught the form-to-CRM failure in March.
Reversibility
Design so that mistakes are recoverable, not just detectable.
Draft, don't publish. A workflow creating a draft post you approve is far safer than one publishing directly, and usually only marginally slower.
Queue, don't send. Schedule outbound messages with a delay, so there's a window to cancel.
Tag, don't delete. Rather than removing records, mark them and clear them out later after review.
Write, don't overwrite. Appending is recoverable. Replacing isn't.
The general rule: prefer the additive version of any operation. Undoing an addition is easy; undoing a deletion usually isn't.
A pre-launch checklist
Before any workflow goes live:
- Error notifications enabled and routed somewhere I check
- Failed items go to a retrievable fallback, not nowhere
- Retries configured for transient failures only, with a cap
- A heartbeat check detects if it stops running entirely
- Irreversible actions have a human checkpoint
- I've tested it failing, not just succeeding
- The manual fallback is documented — what to do while it's broken
That last two matter most and get skipped most. Deliberately break the workflow in a test — revoke a token, feed it malformed data — and watch what happens. Whether it errors loudly, where the data goes, whether you get told.
Most people discover their error handling doesn't work during an actual incident. Finding out on a quiet Tuesday is considerably better.
Frequently asked questions
How do I get alerted when an automation breaks?
Turn on your platform's built-in error notifications — they exist everywhere and are often off by default or routed to an unmonitored address. Send them somewhere you genuinely look, ideally a dedicated Slack channel or mobile push rather than an email inbox. Make the alert specific enough to act on, and add escalation for repeated failures. Critically, add a separate heartbeat check as well, because error alerts don't fire when a workflow simply stops being triggered.
What is a silent failure?
A workflow that completes successfully while doing nothing useful. The trigger stops firing so it never runs and never errors, or a field gets renamed so it writes empty values while reporting success, or a filter starts rejecting everything because the data shape changed. Nothing errors, your dashboard stays green, and you discover it when a customer asks why nobody responded. This is why a heartbeat check watching for absence matters more than error alerting alone.
Should automations retry automatically?
For transient failures, yes — timeouts, 5xx server errors, rate limits, and brief connection problems all resolve on their own. Don't retry authentication failures, missing required fields, or malformed data, since waiting doesn't make a wrong API key correct and you're just burning task allowance while hiding the real error. Cap retries at three to five with exponential backoff, then fail properly into your fallback destination — infinite retries turn a visible failure into a silent one.
What to do next
Take your most important workflow and ask one question: if this stopped running tomorrow, how would I find out?
If the honest answer is "when someone complains," you have a detection problem rather than a reliability problem — and detection is far cheaper to fix.
Add the dead-letter path first. It's the single highest-value pattern here, because it means a broken workflow costs you time rather than leads.
Free: The automation planning checklist.
Related guides
- AI marketing automation — the wider framework
- Is your automation actually saving time? — finding what's already broken
- Human-in-the-loop — checkpoints for irreversible actions
- How to pick your first automation — error cost in the scoring
Join the Newsletter
Get practical marketing tactics delivered straight to your inbox.
Written by
Muhammad Basim
Related Articles
What Marketing Automation Actually Costs at Scale
Nobody's automation bill jumps because they added more automations. It jumps because they added steps to workflows that were already running — a filter here, an enrichment lookup there, a second notification — and the billing model charges for every one of them, on every run. That's the mechanic behind almost every "why did this […]
One Workflow, Three Tools: A Build Comparison
Feature tables don't tell you what a tool is like to use. The only thing that does is building the same thing twice and noticing where you got annoyed. So here's one realistic workflow — lead routing with enrichment and conditional assignment — specified once and mapped across Zapier, Make, and n8n. What changes between […]
GoHighLevel: 7 Automation Workflows to Build First
GoHighLevel gives you a hundred things you could automate, which is exactly why most accounts end up with forty half-built workflows and no measurable result. Seven are worth building first. They're the ones tied directly to revenue — catching leads before they cool, recovering appointments that would otherwise vanish, and asking for reviews at the […]