What Obsevo is

Obsevo watches n8n from outside n8n and raises incidents when something is wrong. It is not a replacement for n8n's error workflow, and it is not a log aggregator you point at n8n — it is a second system that knows what n8n should be doing and notices when reality diverges.

The two failures it exists for

A run that never started. n8n alerts on executions. A schedule that did not fire produces no execution, so there is nothing to attach an error workflow to and nothing in the list to notice. Obsevo reads the cadence from the trigger, so it can tell that 02:00 came and went without a run.

A run that succeeded and did nothing. A run is success when no node threw an error. A scrape whose selector stopped matching, a sync that wrote zero rows, and a perfect run all report identically. Obsevo compares output volume against the workflow's own history.

Both are invisible from inside n8n, and neither is a bug in n8n. They fall outside what an execution record is able to express.

What it does beyond that

• Eight more detectors — failures, consecutive failures, error rate, runtime anomalies, AI cost spikes, SLA breaches, business thresholds and log thresholds.
• A unified log and run timeline, including OpenTelemetry ingest.
• Alerting with routing, quiet hours and escalation.
• Control actions — retry, stop, activate, deactivate.
• Status pages and client workspaces for agencies.
• A read-only public API and a Prometheus endpoint.

What it is not

• Not an APM. It reasons about workflow runs, not about your application's internals.
• Not a log store for everything. It will ingest arbitrary logs and correlate them to runs, but its centre of gravity is n8n.
• Not a replacement for n8n's error workflow. That is still the right tool for handling a failure inside a run. Obsevo covers the cases where there is no run to handle.
• Not a writer, by default. It reads n8n read-only unless you deliberately give it a write-scoped key.

What runs where

Obsevo runs the server. You run, at most, the agent.

That split is the product rather than a deployment detail. The server has to be somewhere your n8n host cannot take down with it — a monitor that dies with the thing it monitors reports nothing at exactly the moment it matters. The agent runs beside n8n precisely because it is on the other side of that boundary: it reduces execution data where the data already is, and pushes only signed metadata out.

If you would rather run nothing at all, API-key mode skips the agent and polls n8n directly.

Plans differ in scale — instances, retention, monthly volume — and in the operational surface built on top. They never differ in detection quality, and users are unlimited on every plan.