Docs
How detection works
The ten detectors, with their actual thresholds. These are behaviour, not settings — the numbers are here so you can predict what will fire.
Every detector is a pure function over a run and that workflow's own recent history. There is no global "sensitivity" dial, and the thresholds below are not configurable per workspace — they are published so you can predict what will fire rather than tune it until it stops.
Detection is never limited by plan. Everything on this page runs on the free tier exactly as it runs on Agency.
The two that justify the product
Missed runs
From the last observed run and the trigger's cadence — a cron expression or a fixed interval — Obsevo computes when the workflow should next have run. Past that time plus a five-minute grace, with no run, it raises an incident.
Interval cadences are floored at 60 seconds, so a sub-minute schedule cannot produce an alert storm. A workflow that has never run is skipped rather than alerted on, and an unparseable cron expression is skipped rather than guessed at.
This needs a schedule it can read. A webhook-triggered workflow has no cadence to infer, so it cannot be covered by this detector.
Green-but-broken
Two rules, over the totalItemsOut of recent successful runs of the same
workflow:
- Hard rule → critical. At least 5 successful runs in the baseline, a historical minimum of at least 1 item, and this run produced 0. Meaning: it has always returned something, and today it returned nothing.
- Soft rule → warning. At least 10 runs, and this run is more than 3 standard deviations below the mean and below half the mean. Both conditions, so a noisy workflow does not alert on ordinary variance.
The five-run minimum is why a brand-new workflow is not called broken for having no history.
The rest
| Detector | Fires when |
|---|---|
| Failure | n8n reported an error. The summary names the failing node and the error, truncated |
| Consecutive failures | 3 failures in a row, including this run. Separate from single failures so it can route to a louder channel |
| Error rate | Over a rolling 1 hour window with at least 10 runs: 25% failed → warning, 50% → critical |
| Runtime anomaly | A successful run more than 3σ above its mean duration and more than 1.5× the mean, over at least 10 runs |
| AI cost spike | Spend more than 3σ above the mean, and more than 2× the mean, and at least $0.50 in absolute terms |
| SLA breach | Error budget for the window is being consumed faster than the target allows, with a minimum of 20 runs. Warns at 80% of budget burned |
| Business threshold | A KPI you send from the n8n node moves outside the range you set |
| Log threshold | Log volume or severity from a source exceeds the rule you configured |
The error-rate detector uses a rolling time window rather than a fixed count, so a busy workflow and a quiet one are judged on the same terms.
The cost-spike detector requires all three conditions because any one alone produces noise: a percentage on a tiny number, a multiple on a rounding error, or an absolute figure on a workflow that is simply expensive. n8n reports these runs as successful, so nothing else in the stack will flag them.
Severity
Three levels — info, warning, critical — which drive
channel routing, quiet-hours filtering and escalation.
Errors are classified into buckets (timeout, rate_limit, auth, http_5xx,
http_4xx, validation, other) for filtering and grouping. The classification
is metadata only; the message itself is not stored on the incident.
The detectors
Each detector is small and independent, with its own defaults and its own tests:
green-but-broken— five successful runs, a historical minimum of one item, and zero items this runmissed-run— a schedule that did not fire inside its expected window- plus the rate, duration, SLA and business-threshold detectors