WARNING · Nightly Shopify → NetSuite sync (prod-eu)
Workflow "Nightly Shopify → NetSuite sync" was expected to run by 2026-07-29T02:00:00.000Z but hasn't (overdue 47 min)
https://app.obsevo.com/i/9f2c4d18
Free tier · no credit card · payloads stay on your host
The n8n failures nobody alerted you about.
Obsevo watches n8n from outside n8n. It catches the runs that never started and the runs that reported success while producing nothing — the two failures that leave no error for anything else to find.
#alerts · slack
CRITICAL · Lead scraper (prod-eu)
Workflow "Lead scraper" succeeded but returned 0 items (normally ~1240)
https://app.obsevo.com/i/a41b7c2e
There is nothing to install on our side.
Sign up, connect an n8n instance, and run one container next to it. The agent computes on your infrastructure and pushes only metadata — or skip it entirely and connect with an n8n API key.
docker run -d --name obsevo-agent --restart unless-stopped \
-e OBSEVO_INGEST_URL=https://ingest.obsevo.com/ingest \
-e OBSEVO_INSTANCE_ID=<from the dashboard> \
-e OBSEVO_INGEST_SECRET=<from the dashboard> \
-e OBSEVO_N8N_URL=http://n8n:5678 \
ghcr.io/obsevo/obsevo-agent:latestThe gap
Two failures n8n cannot report
Neither of these is a bug in n8n. They fall outside what an execution log is able to describe.
A run that never started
n8n alerts on executions. A schedule that didn’t fire produces no execution, so there is nothing to attach an error workflow to and nothing to see in the list. The workflow is simply absent, and absence is invisible.
Obsevo knows the cadence from the trigger, so it can notice that 02:00 came and went.
A run that succeeded and did nothing
A run is success when no node threw. A scrape whose selector stopped matching, a sync that wrote zero rows and a perfect run all report the same status.
Obsevo compares output volume against the workflow’s own history, so “this has always returned about 1,200 rows and today returned none” becomes an incident.
Three questions
- If your 2am sync didn’t fire last night, when would you find out?
- How many rows did it actually write?
- If the n8n box is down right now, what tells you?
If the honest answer to any of these is “when someone downstream complains”, that is the gap. It is not a monitoring configuration problem — there is no execution to configure monitoring against.
Why it runs outside
Monitoring that lives on the box it monitors is not monitoring
The usual answer to n8n alerting is an error workflow. It is a good tool and it stops at the same boundary n8n does: it runs inside n8n, it is triggered by an execution, and it cannot fire for a run that never happened or one that reported success.
- Survives the host
- If the n8n container dies, an error workflow inside it dies with it. Obsevo is a separate process, usually on separate hardware, and notices the silence.
- Outlives n8n's pruning
- n8n prunes execution history on its own schedule, and many installs save nothing at all on success. Obsevo keeps its own record.
- Sees across instances
- Workflows split across staging and production, or across client installs, share one timeline.
Where your data goes
The agent computes locally and sends numbers
The agent runs beside your n8n, reads it read-only, and pushes signed metadata outbound over HTTPS. It never opens a port and never receives a callback, so it works from inside a private network.
What leaves your host, in agent mode
- Workflow and node names, and run status
- Timings, item counts and error text
- Model name, provider and token counts for AI nodes
- Execution payloads
- Prompt and completion content
- Credentials
Detection
Ten things it watches for
Thresholds are published rather than described, because a threshold you cannot see is a claim you cannot check.
Missed runs
A scheduled workflow that should have run and did not. Derived from the cron or interval on the trigger, so it fires on the absence of an execution — the case n8n has nothing to alert on.
Green-but-broken
A run n8n marked success that produced no output. Fires as critical when a workflow with at least five successful runs that has always returned items returns none.
Failures
A run that errored, summarised with the node that failed and the error it raised.
Consecutive failures
Three failures in a row, kept separate from single failures so it can be routed to a louder channel.
Error rate
The share of runs failing over a rolling window rather than a fixed count, so a busy workflow and a quiet one are judged on the same terms.
Runtime anomalies
A successful run that took more than three standard deviations and 1.5× longer than its own history.
AI cost spikes
A run whose model spend is an outlier on all three of sigma, multiple and an absolute floor. n8n reports these runs as successful, so nothing else in the stack flags them.
SLA breaches
Error-budget arithmetic per workflow. “You have three failures left this month” is a decision; “99.2% versus 99%” is trivia.
Business thresholds
Your own KPIs, sent as events from the n8n node, alerting when a number moves outside the range you set.
Log thresholds
A burst of log volume or severity from a workflow, instance or source.
Detection is never limited by plan.
Every detector above runs on every plan, including the free tier. Paywalling them would make the free tier a worse product rather than a smaller one. Plans sell scale — instances, retention — and the operational surface built on top.
Alerting
Bring your own Slack
Slack, Discord, Telegram, email and signed webhooks. All bring-your-own credentials, all included on every plan including the free tier, and none of them cost anything on top.
The webhook channel is the escape hatch for PagerDuty, Opsgenie or n8n itself, so Obsevo does not have to integrate with everything.
- Scope and severity per channel
- Route one instance, one client or one severity somewhere specific. Consecutive failures can be louder than a single failure.
- Quiet hours
- A UTC window that wraps midnight, with a minimum severity that still gets through.
- A rate cap
- Sixty alerts an hour per workspace by default. The thing being protected is the human's attention, not the webhook.
- Escalation
- An incident nobody has touched is re-offered to another channel after a delay you set.
Control
And you can act on it
Retrying from the incident beats finding the run again in another tab. But a monitoring tool holding a write-capable key is a real thing to be careful about, so the constraints are part of the feature: it is opt-in, it needs a separate write-scoped n8n key, it is restricted by role, and every action lands in an audit log.
Nothing in the control path reads or transports execution payloads. A retry is run by n8n against its own stored data.
Every write Obsevo can make
- Retry an execution
- Stop a running execution
- Activate a workflow
- Deactivate a workflow
Getting started
Free until it is worth paying for
The free tier is a smaller product, not a worse one — every detector runs on it, and there is no card and no trial clock.
Free
No card · all ten detectors
One n8n instance, alerts to your own Slack, Telegram, Discord or email. Enough to find out whether anything has been failing quietly — which is usually the question.
Paid plans
From $29/mo · unlimited users
More instances, longer history, the public API, and the client-workspace and white-label pieces agencies need. Seats are never the lever — every plan includes unlimited users.
What it does not do
- Green-but-broken needs about five runs of history before it can judge a workflow.
- Missed-run detection needs a schedule it can read — it cannot infer one for a webhook-triggered workflow.
- The real-time capture hook requires an n8n you host yourself. On n8n Cloud, Obsevo polls instead.
- Obsevo reads n8n read-only unless you explicitly give it a write-scoped key.
- There is no SMS channel, and no SLA on the free tier.
Obsevo is pre-1.0 and under active development.
Start free