The dangerous thing about a broken automation is not that it stops. It is that it stops without telling anyone, while everybody continues to believe it is running. Manual processes fail loudly — someone notices the pile of unprocessed work. Automated ones fail quietly, and the discovery usually comes weeks later, from a customer. After enough builds you notice the failures cluster into a small number of shapes, and all seven are preventable at design time for almost no extra effort.
1. Silent failure
This is the meta-failure that makes all the others worse, so it goes first.
An automation errors. The platform records it in a log. Nobody reads the log, because nothing prompted them to. The automation is not running, everybody assumes it is, and the manual fallback everyone used to do has been dismantled because the automation handles it now.
The gap between failure and discovery is the entire damage. A workflow that breaks and is fixed in an hour is a non-event. The same workflow discovered three weeks later by a customer asking why nobody replied is a different kind of problem.
Two things, and they are different. Error alerting tells you when something ran and failed. Heartbeat monitoring tells you when something did not run at all — which is the harder and more common case, because a workflow whose trigger silently stopped firing produces no errors to alert on. If a workflow should run daily and has not run in 36 hours, that should reach a person.
2. Duplicate delivery
Webhook systems generally guarantee at-least-once delivery, not exactly-once. If your endpoint is slow, times out, or returns an error, the sender retries. Your handler will legitimately receive the same event more than once.
Handled naively, the customer gets two confirmation emails, the order is created twice, the invoice is raised twice, or the commission is paid twice. Every one of those has happened to a real business, and the last two cost money directly.
The fix is small and non-negotiable: record the event ID of everything you process, and check that record before doing any work. Seen it before, acknowledge and stop. This is three lines of logic that separates a webhook handler that is correct from one that is usually correct.
Two related habits. Acknowledge fast, process after — return success immediately and do the real work asynchronously, so a slow downstream system does not cause the retries that create the duplicates in the first place. And verify the signature on incoming webhooks, so you know the event came from who you think rather than from someone who guessed your URL. Both Stripe and Shopify document this well and it applies to every provider.
3. Position-based references
The classic spreadsheet failure, and the most quietly destructive on this list because it produces wrong data rather than no data.
An automation is written to update "row 47". Someone sorts the sheet. Row 47 is now a different customer. The automation keeps running, reports success every time, and writes the wrong information to the wrong record indefinitely. There is no error anywhere.
The same shape appears in other guises: referencing columns by letter when someone might insert a column, or referencing a list item by index when the list order is not guaranteed.
The fix is to reference identity rather than position. Give every row a unique ID, generated once and never reused, and look records up by ID. Address columns by header name rather than letter. This is the single most valuable habit in spreadsheet-backed automation, and it is why tools with stable record IDs like Airtable are worth the money once workflows depend on the data.
4. Credential expiry
Most integrations authenticate with tokens that expire. Well-built connections refresh them automatically. Then a password changes, or someone revokes an app, or a refresh cycle fails once and is not retried, and the connection dies.
What makes this one nasty is the delay. The automation works perfectly for four months, which is long enough for everyone to stop thinking about it and for the manual fallback to be forgotten. Then it stops.
Three things help. Use a service account rather than an individual's login wherever the platform allows it, so that a person leaving does not take the integration with them — this is a surprisingly common cause. Alert explicitly on authentication failures, separately from ordinary errors, because they mean something different and need a different response. And keep a written register of every integration, which account it authenticates as, and who owns it. That document takes twenty minutes and saves a day.
5. Assumed data shape
Automations are built and tested against tidy examples. Then reality arrives: an empty phone number, an apostrophe in a surname, a name in a different alphabet, a date typed as free text, a field that is usually a number and is occasionally the string "N/A", or two hundred characters where the automation expected twenty.
Sometimes this errors, which is the good outcome. Often it does not — it produces an email addressed to "Dear ," or a record with a mangled field, or a number silently truncated. The automation reports success.
Validate at the boundary. Every piece of data entering a workflow from outside should be checked against what you expect before anything acts on it, and anything failing the check should go to a person rather than proceeding on a guess. This matters most where a language model produces the data, because a model will always return something confidently formatted whether or not it is correct.
When you test, test with the ugly cases deliberately. Empty fields, duplicate submissions, the longest input anyone could plausibly enter, and a name with an apostrophe in it. Those are what actually arrive.
6. Timezone and date drift
A category of its own because it causes such specific and embarrassing failures: reminders sent at three in the morning, appointments recorded on the wrong day, a "daily" report that runs twice on one day a year and not at all on another.
The causes are mundane. Different systems defaulting to different timezones. Daylight saving transitions. A platform storing local time while another stores UTC. Date strings parsed with an assumed format, so 03/04 is March in one system and April in the next.
The rule is simple and worth applying from the first line: store and transmit everything in UTC, convert only for display, and use an unambiguous format — ISO 8601 — everywhere in between. Getting this right costs nothing at the start and is genuinely unpleasant to retrofit once wrong dates are already in your data.
7. Unbounded growth
The failure that arrives with success. An automation built for the volume you had works fine, then volume grows and it does not.
It shows up in several forms. A spreadsheet that was fast at five hundred rows and is slow at fifty thousand. An API rate limit you never approached and now hit daily. A workflow that processes "all open records" and gets slower every month because nothing archives them. A task-based bill that was trivial and is now a real line item — which is the per-step pricing problem in a different costume.
Design for the volume you expect in two years rather than the volume you have. Concretely: process in batches rather than loading everything at once, archive completed records on a schedule so the working set stays small, respect rate limits with backoff rather than retrying immediately, and put a usage number on a dashboard where someone will see it trending before it becomes a problem.
The checklist
Before an automation is considered finished, all seven of these should have an answer.
- Who is told when this fails, and how — including when it fails by not running at all?
- What happens if the same event arrives twice?
- Does anything reference a position, a row number or an index rather than a stable identity?
- Which account does this authenticate as, and what happens when that person leaves?
- What does it do with an empty field, a duplicate, or an unexpected format?
- Is every date stored in UTC and formatted unambiguously?
- What breaks first at ten times the current volume?
None of this is difficult. It is all cheap at design time and expensive afterwards, which is exactly the profile of work that gets skipped. Two hours of this discipline is the difference between an automation that runs for three years and one that quietly stops in month four.
If you are choosing what to build in the first place, start with how to decide what to automate first. If the process needs a person in the middle — and the high-error-cost ones usually do — the human-in-the-loop pattern covers where to put them.