What OutcomeGuard does
OutcomeGuard reads your n8n instance through its public REST API, learns how each workflow normally behaves, and tells you when a workflow stops doing its job — including the cases where n8n still reports success.
It never writes to your instance. Everything below is read-only, and nothing runs inside n8n itself.
Before you start
- An n8n instance, self-hosted or n8n Cloud, reachable over HTTPS.
- Permission to create an n8n API key on that instance.
- A few workflows with some execution history. OutcomeGuard needs history to know what normal looks like; a workflow created an hour ago will be reported as insufficient data until it has run enough times.
Step 1 — Connect the instance
- In n8n: Settings → n8n API → Create an API key.
- Copy the key.
- In the dashboard, add an integration and paste the instance URL and the key.
- Save. OutcomeGuard verifies the connection immediately and tells you if the URL or the key is wrong.
The key is encrypted before it is stored, and it is never written to logs. See the connect-n8n page for URL requirements and troubleshooting.
Step 2 — Choose what to monitor
OutcomeGuard lists every workflow it can see. Select the ones you want monitored, up to your plan's limit. Start with the workflows that would cause a phone call if they stopped: billing, lead routing, daily imports, anything a customer sees.
You can change the selection at any time. Deselecting a workflow stops monitoring it and leaves the rest untouched.
Step 3 — Let the baseline form
For each monitored workflow, OutcomeGuard reads the recent execution history and learns its cadence, its typical duration, its typical item count, the node successful runs usually end on, and how often an empty result is genuinely normal.
Hard failures — errors, crashes, auth failures — are reported from the first poll. The statistical detections wait until there is enough history, and a workflow in that state is listed as insufficient data rather than as healthy or broken.
Step 4 — Set where alerts go
Add the email recipients for the workspace in the dashboard. One incident produces one email, with the evidence attached; a continuing problem escalates rather than repeating.
Send a test alert once so you know what it looks like, and so you find out now if it lands in a spam folder.
Step 5 — Define what “done” means
For your two or three most important workflows, write an Outcome Contract: the deadline, the minimum item count, the maximum runtime, and where relevant a downstream probe that confirms the target actually changed. This is the difference between knowing a workflow ran and knowing the work got done.
The Outcome Contracts page explains each rule type and walks through a complete example.
What the first day looks like
- Within minutes: failing workflows, auth errors, deactivated workflows and unreachable instances.
- Within a few hours: missed scheduled runs, because OutcomeGuard now knows when the next run was due.
- Within a few days: the statistical detections — silent failures, empty output, volume and latency anomalies — as the baselines settle.
If you want a snapshot before connecting anything, run the free health check first. It uses the same engine and discards the API key when it finishes.