We get called in to fix automations somebody else built often enough that a pattern has emerged. The failures are not exotic. They are the same eight things, in roughly the same proportions, on every platform.
1. Credential expiry, roughly a third of cases
An OAuth token expires, a service account is deactivated when somebody leaves, an API key is rotated as part of a security exercise. The workflow starts failing at the authentication step and, because there is no alerting, nobody notices for an average of eleven days.
Prevention is cheap: use service accounts not personal accounts, monitor token expiry dates as a scheduled check, and alert on authentication failures separately from other errors because they mean something different.
2. Third party API changes, about a fifth
A provider deprecates a version, renames a field, changes a response shape, or tightens a rate limit. Providers do announce these. The announcement goes to an email address nobody monitors.
The mitigation is version pinning where the API supports it, schema validation on responses so a shape change fails loudly at the boundary rather than corrupting data three steps later, and a subscription to the provider's changelog that actually reaches a human.
3. Missing idempotency, about a sixth
This one produces the most expensive damage. A webhook fires twice, a retry runs after a partial success, somebody replays a queue. Without an idempotency key, you get duplicate invoices, duplicate orders, duplicate emails to the same customer.
The fix is a natural key on every write: source event id, or a hash of the meaningful fields. Check before writing. It takes twenty minutes at build time and prevents the failure mode that costs the most to clean up.
Duplicate records are the most expensive automation failure, and the cheapest to prevent.
4. Unhandled data shape variation
The workflow was built and tested against twenty records that all looked similar. Then a record arrives with a null where there has always been a value, an accented character in a field that gets used in a filename, a date in a different format, or an array where a single object was expected.
Test against real historical volume before going live. We replay a month of actual records through every workflow we build, and it finds something roughly nine times out of ten.
5. Rate limits handled by waiting
The workflow hits a rate limit, catches the error, waits a fixed period, and retries. Under light load this works. Under real load, every retry collides with every other retry and the whole thing degrades into a queue that never drains.
Exponential backoff with jitter, respect for the Retry-After header when the provider sends one, and batching where the API supports it.
6. No environment separation
There is one instance. Changes are made in it. The change is the test. This is fine right up until the change is wrong, at which point production is broken and there is no version to roll back to.
Even a lightweight separation helps: a second workspace, a flag that routes writes to a sandbox, credentials that point at test accounts. It does not need to be elaborate, it needs to exist.
7. Silent failure
The workflow has no error branch. When a step fails, the run stops. The platform records a failed execution in a log nobody reads. From the outside, nothing happened, which is indistinguishable from nothing needing to happen.
Every workflow needs a failure path that reaches a human. Not an email to a shared inbox, a message in a channel somebody is accountable for.
8. Undocumented and unowned
Strictly this is not a technical failure, but it is the reason the other seven take weeks to fix instead of hours. The person who built it has left. There is no documentation. Nobody is quite sure what it connects to or whether it is safe to turn off.
If your automation estate has no inventory, start there. You cannot maintain what you cannot list.
The pattern underneath
Every one of these is a failure to plan for the unhappy path. Building the happy path is the easy eighty percent, and it is the part that gets demonstrated in the meeting where the work is approved. The other twenty percent is what determines whether the thing is still running in a year.
Written from work we have actually delivered. If your situation looks like the one described here, the quote form takes about two minutes and there is no sales sequence attached to it.
Get a free quote