The maintenance gap · 03

Silent automation failures: the hidden cost.

The Zap ran perfectly for fourteen months. Then one Tuesday it stopped - no error on your screen, no email, nothing. The website forms kept submitting, the leads kept arriving, and every one of them fell into the gap between two tools. You found out on Friday, from an annoyed prospect who'd "filled in the form twice." Everyone who runs automations has a version of this story.

Why the glue goes quiet

Connector tools - Zapier, Make, n8n and friends - are brilliant at their job, which is moving data between systems they don't own. That last part is the root cause. Because the glue owns neither end of the connection, it can only react to what the ends tell it, and the ways they stop telling it are many:

• Token expiry. An OAuth connection quietly lapses; the automation authenticates into a void.
• API changes. The connected app renames a field, deprecates an endpoint, or restructures a webhook - as users describe on automation forums: Zaps that worked for years stop suddenly and without notice.
• Rate limits and plan changes. Calls start getting rejected; the automation shrugs.
• Trigger drift. The event that fired the automation stops firing - and no runs looks identical to no work to do.

That last one is the killer. A monitoring system that only watches executions can't distinguish "nothing to process" from "the trigger is dead." Silence looks like peace.

The arithmetic of not knowing

The cost of a silent failure is a simple multiplication: value per run x runs missed x days until discovery. The third factor is the dangerous one, because discovery-by-accident routinely takes days. One practitioner's public account: a form-notification automation failed silently, and by the time it was noticed three days later, a four-figure client had gone elsewhere. For an agency running the same lead-routing pattern across many clients, multiply again - every silent break is happening on someone else's revenue, under your name.

How to make failure loud

1. Monitor outcomes, not executions. Zero runs on a normally-busy Tuesday is itself an alarm. Track expected volume, not just errors.
2. Retry transient failures automatically. Most API hiccups are temporary; retries with backoff absorb them without human involvement.
3. Alert a human on final failure. Email or Slack, within minutes - not a dashboard someone might check.
4. Log every run. When something does break, the diagnosis starts from a record, not from archaeology.
5. Know your dependencies. A renamed field should be flagged before it breaks the three workflows using it - which requires the system to know what depends on what.

You can retrofit some of this around a connector tool - error-handler paths, watchdog automations that watch the automations. It works, and it's more plumbing for the pile that somebody has to maintain.

Or run automations on a system that owns both ends

The structural fix is to stop gluing and start owning: when the data, the workflows, and the UI live in one system, silence becomes detectable. That's how Chromoly is built - every automation run is logged, failed steps retry with backoff, AI steps fall back across providers, final failures alert you within minutes, and a dependency map flags breaking changes before they ship. In-flight runs always finish, even when credits run out. The full comparison with the glue-tool approach is on the Zapier alternative and n8n alternative pages - including the honest note that their connector catalogs are bigger. What they can't offer is the guarantee this page is about: nothing breaks without warning.

Frequently asked questions