85% of failures alerted nobody: what an opt-in safety net costs at 225 workflows

Take the two percentages together and the failure counts fall out. 0.21% of 50,669 executions is about 106 failed runs in the six-day window ^[1]. Sixteen of those belonged to workflows with an error handler attached ^[10], which leaves roughly 90 that ended their lives in the executions list and nowhere else ^[2].

The more useful comparison is between coverage and blame. 43% of 225 workflows is about 97 guarded and 128 not ^[3]. The guarded 43% produced about 15% of the failures, which puts the per-workflow failure rate on the unguarded side at roughly four times the guarded side ^[4]. Both figures are reconstructed from a rounded percentage, so treat the 4x as a direction rather than a measurement. The direction is the interesting part: guarding tracks attention, and so does not failing. The workflows nobody remembered to point at the handler are the same workflows nobody was looking at for any other reason.

None of this changed how often things broke. The author is explicit that the Error Trigger does not buy fewer failures, only shorter ones ^[11]: 1.2 hours at worst with a handler, 70.9 hours at worst without ^[10][8], a factor of about 59 in how long a broken automation stays broken ^[5]. The WhatsApp contact gate failed 24 times across a weekend and was found on Monday by accident, while the executions list was open for an unrelated reason ^[9].

The recursion underneath is worse than the coverage gap. All three handler workflows were themselves unguarded, and a handler cannot report its own failures, because the thing that reports failures is the handler ^[13][14]. The obvious patch, pointing handler A at handler B, relocates the single point of silence by one hop and adds a cycle you will forget about ^[15]. Whatever watches the catcher has to live outside n8n ^[15].

Full coverage would still leave a category dark. The Error Trigger fires when an execution fails, not when an execution never starts: a deactivated trigger, a dead cron, a webhook whose URL moved, a worker that is not consuming the queue ^[19]. A workflow that has stopped running produces zero failed executions and therefore zero alerts, which is indistinguishable from a quiet week ^[19]. Coverage is answerable with one query against the workflow table's settings column, or the equivalent read of settings.errorWorkflow on Cloud ^[16][17]. Liveness is not, and needs an instrument that knows what should have run.

That query earns its place in the weekly runbook next to the backup check ^[18] for a structural reason, not a disciplinary one: it is external to the thing it inspects, and it runs whether or not anyone remembers workflow #61.