What happens when an automation breaks?
A well-built automation stops, alerts a named person, and leaves the underlying data untouched. A badly built one keeps running with wrong data and nobody notices until a customer complains. The difference is entirely down to whether error handling, retry logic and failure alerting were designed in from the start — they cannot be added convincingly afterwards.
Expect something in a busy automation stack to need attention every few months. APIs get versioned, OAuth credentials expire, vendors deprecate endpoints, and someone renames a column in a spreadsheet. The question is never whether it breaks; it is whether you find out from an alert or from an angry email.
The five ways automations actually break
1. Credentials expire
By far the most common. An OAuth token has a lifetime, a service account password hits a rotation policy, or an API key was tied to the personal account of someone who has since left the company. The automation was fine yesterday and is dead today, through no change of yours.
2. A vendor changes their API
A field gets renamed, an endpoint is deprecated with ninety days notice in a changelog nobody reads, a response format changes, or rate limits tighten. Every integration outlives at least one of these.
3. The data changes shape
Someone adds a column to the spreadsheet, renames a pipeline stage in the CRM, or starts entering dates in a different format. The automation is working exactly as built; the world moved underneath it.
4. An assumption stops holding
The workflow assumed every order has a purchase order number. Then sales started taking phone orders without one. Nothing is technically broken — the logic simply never anticipated this, and now it does something unhelpful with it.
5. A dependency has an outage
The API is down, the platform is degraded, the network hiccups. Usually transient, usually resolved in minutes — but what the automation does during those minutes is a design decision, not an accident.
Why silent failure is the dangerous one
Failures divide into two categories, and they are not equally bad.
Loud failures stop the automation and raise an error. Annoying, visible, fixable. You know immediately, the data is untouched, and you can fall back to doing it manually while it is repaired.
Silent failures keep going and produce wrong results. The invoice posts to the wrong account. The lead routes to the wrong salesperson. The sync writes an empty field over good data. Nothing errors, nothing alerts, and the corruption compounds daily until someone notices — often weeks later, often via a customer.
A month of quietly wrong data costs far more than a day of visibly stopped automation.
Good engineering deliberately converts silent failures into loud ones. That is what validation is for: rather than letting an unexpected value pass through, you check it, and if it fails the check you stop and shout. It feels more fragile. It is dramatically safer.
What a properly built one does
Every workflow we build ships with all six of these, because an automation without them is a liability rather than an asset.
- Retry with backoff. Transient failures — a timeout, a 503 — are retried a few times with increasing delays before anything is declared broken. Most outages resolve themselves inside this window and nobody ever knows.
- Idempotency. A retry cannot create a duplicate. If the automation is unsure whether the invoice was created, it checks rather than creating a second one.
- Validation before writing. Data is checked against expected shape and against your own records before anything is committed. Failing the check stops the run.
- A dead-letter queue. Records that cannot be processed go somewhere visible with the reason attached, instead of vanishing. Nothing is silently dropped.
- Alerting to a person. Failures notify a named human via Slack, Teams or email, with enough context to know what broke and what it was doing. Not a dashboard somebody might check.
- A documented manual fallback. What your team does while it is down, written out. Vendors have outages; the business still has to run.
Hard errors are the easy case. The subtler monitoring is for a scheduled workflow that simply stopped triggering, a sync falling steadily behind, or a queue growing when it should be draining. Nothing has errored, but something is wrong. Monitoring only for exceptions misses this entire class.
Who fixes it
There are two honest models, and both are fine as long as you have consciously chosen one.
Your team. Every build should hand over with documentation, a runbook and alerts pointed at your own people. Plenty of businesses run it themselves from here, particularly if someone internal is comfortable in the platform. This is a real option, not a fallback, and no competent firm should make you feel otherwise.
A support retainer. Alerts route to whoever built it, fixes are included in a flat monthly fee, and the platform maintenance — credential rotation, connector migrations, version upgrades — gets done without anyone internal owning it. Ours start at $1,500 a month; see automation support.
The failure mode to avoid is having neither: alerts pointed at a shared inbox nobody owns, documentation that was never written, and an assumption that it will keep working because it has so far.
Checking what you already have
If you have automations running now that somebody else built, these five questions will tell you where you stand.
- If it failed right now, who would find out, and how? If the honest answer is "eventually, from a customer," that is the finding.
- Whose credentials is it using? If they belong to an individual rather than a service account, you have a resignation-shaped outage waiting.
- What happens to a record it cannot process? If the answer is "I don't know," it is being dropped.
- Where is it documented? Scenario names are not documentation.
- When did it last run successfully? Not "is it enabled" — when did it actually last do its job? These are different questions and the gap between them is where the surprises live.
This is exactly what a takeover assessment covers: inventory what exists, map what it touches, identify what is fragile, and document it properly. You keep the documentation regardless of what you do next, which for most businesses in this position is worth the fee on its own.
Something already broken?
Tell us what you have running and what is going wrong. If it is a quick fix we will say so.