How WorkflowPulse detects silence - the actual algorithm

Error monitoring is a solved problem: something throws, you get a message. The failure mode that actually costs money is the opposite one - a workflow that stops being triggered and therefore never throws anything. A rotated webhook key, a trigger toggled off mid-edit, a dead cron: from n8n’s point of view, nothing went wrong. Nothing ran.

This post is the complete description of how we detect that, with the real constants from our detection engine. If you want to evaluate whether to trust it, this is the material.

Step 1: learn each workflow’s cadence

For every monitored workflow we record the gaps between consecutive executions and keep two statistics over a rolling 14-day window: the 95th-percentile gap (gapP95) and the longest gap ever observed healthy (gapMax). No schedules to configure, no cron expressions to mirror - the workflow’s own history is the model.

Step 2: refuse to guess early

Detection stays in learning mode until we have at least 10 gap samples and 7 days of observation. A monitor that alerts off three data points is a random-noise generator with a logo. Until both thresholds are met, the workflow’s silence status is “learning” and it cannot fire.

Step 3: the trigger condition

A silence incident opens only when both of these hold:

• The current gap exceeds max(2 × gapP95, 30 minutes) - for workflows you mark critical, max(1.5 × gapP95, 15 minutes).
• The current gap also exceeds gapMax - the longest gap this workflow has ever survived healthy.

The second condition is the one that matters in practice. Plenty of workflows are bursty-but-healthy: busy all day, dead quiet overnight. A multiple of the p95 alone would page you every night at 1 AM. Requiring the gap to beat the workflow’s own historical maximum means the alert can honestly say: “Longest gap in the last 14 days was 6 hours. It has now been 14 hours.” That sentence is the whole pitch - it tells you why this is anomalous, not just that a threshold tripped.

Prefer explicit control? Set an expected interval per workflow and we alert at 1.5× it, skipping the learned model entirely.

Step 4: suppress in the right order

Firing correctly matters less than not firing stupidly. Before a silence incident opens, four suppressions run in strict priority order:

1. Deactivated in n8n beats everything.If someone switched the workflow off, that is the story - you get a “was deactivated” notice, and any open silence incident resolves as explained. No mystery hunt for a switch someone flipped.
2. Root cause beats symptom. If the instance itself is down or its API key stopped working, every workflow on it will look silent. You get one instance-level incident, not thirty silence alerts describing the same outage.
3. Unobserved is unknown, never silent. If we could not watch - our poller was down, or history was pruned before we could read it - that window is marked unknown and can never produce a silence incident. A monitoring tool that converts its own blind spots into your incidents is worse than no monitoring at all. (One refinement: when a gap in our observation heals - polling resumes and cursor pagination backfills every execution that happened during the outage - the gap no longer blinds detection, because nothing was actually lost.)
4. Snooze windows. Known-quiet hours, org-local timezone, per workflow.

Step 5: close the loop

The first execution after an incident opened resolves it automatically - “✅ running again”- with the total quiet duration. Alerts that never say “it’s over” train you to ignore them.

The secondary signal: volume drops

Total silence is the extreme case. For workflows that run many times an hour there is a subtler failure: still running, but at a fraction of normal volume. For those we compare hourly execution counts against the workflow’s baseline for that hour of the week and raise a warning-level incident when volume collapses - typically one branch of a workflow dying while the rest limps on.

What this does not do

It does not read your execution payloads (we never store those), it does not guess during learning, and it does not pretend to see windows it didn’t observe. Those constraints are why the alerts it does send are worth waking up for.

Start monitoring free - silence detection arms itself once it has learned your patterns. Or read what we store and never store.