The failures that hurt are the quiet ones

Ask an agency operator what breaks and they rarely describe a crash. Crashes are easy — something throws, you get an alert, you fix it. The expensive failures are the ones that look like nothing happening.

“It was the ones that just quietly stopped firing and nobody noticed for a day or two.”

r/n8n, Jul 2026

Why silence is the default

Most automation monitoring watches for errors. But a large share of real-world failures never produce one:

• An OAuth token expires. The integration returns 'unauthorised', the workflow catches it, and the run completes 'successfully' with zero records processed.
• A trigger silently stops. A webhook is deregistered or a poll quietly fails — there is no run at all, and a system that only reports runs has nothing to report.
• An upstream API changes a field name. Data flows, the workflow succeeds, and every downstream record is subtly wrong.
• A rate limit throttles a batch. Ten of five hundred records go through. Technically a success.

In all four cases an error-only alert stays quiet. The first person to notice is the client, and by then you are explaining rather than fixing.

What actually catches it

The shift is from watching for failure to watching for absence — from 'tell me when something breaks' to 'tell me when something that should have happened didn't'.

• Expected-run monitoring: this workflow runs hourly; it has not run in three hours; that is the alert.
• Volume baselines: this job normally processes 40-60 records; today it processed zero; the run status is irrelevant.
• Credential expiry as a first-class event, checked before it bites rather than discovered after.
• A per-client view, so the question 'is everything fine for this client?' has an answer that is not 'let me check seven instances'.

The honest version of this advice

You can build most of this yourself, and sophisticated operators do. One practitioner in the same community runs a dedicated error workflow across 52 workflows that pushes alerts to a channel — that is a real solution and it works.

What self-built monitoring tends not to cover is the absence case, because 'nothing happened' is harder to detect than 'something threw'. If you build nothing else this quarter, build the check that fires when a run does not.

We are building Tenvik partly around this problem, so weigh the framing accordingly — but the failure modes above are drawn from what operators describe, not from our roadmap.