How OutcomeGuard works
Six stages, from a read-only API key to an alert you can act on. Nothing runs inside your n8n instance, and nothing is written back to it.
- 1
Connect
You create an n8n API key and paste it with your instance URL. OutcomeGuard talks to the n8n public REST API and nothing else. Self-hosted instances and n8n Cloud both work.
- 2
Baseline
OutcomeGuard reads each workflow's execution history and learns its own normal: how often it runs, how long it takes, how many items it emits, which node it usually finishes on, how often an empty result is genuinely expected.
- 3
Monitoring
From then on each poll collects a summary per execution — status, start, duration, item count, last node executed, redacted error text — plus a hash of the workflow definition.
- 4
Detection
Every workflow is judged against its own baseline and its declared schedule. Cron and interval triggers are parsed with their timezone, so a run that should have happened at 08:30 JST is missing at 08:30 JST, not at 08:30 UTC.
- 5
Verification
Where you defined an Outcome Contract, OutcomeGuard checks the outcome after the deadline: did it run, did it succeed, were there enough items, was it fast enough, and did the downstream probe confirm that the target actually changed.
- 6
Report
Findings become one incident per problem, deduplicated with a cooldown and escalation so an outage is one email rather than forty. Monthly reports are included on the Pro and Agency plans.
Each stage only passes on what it can prove. A stage with too little evidence reports insufficient data and stops.
Every finding shows its work
A finding is never just a label. It carries the signal type, the evidence rows behind it, the timestamp, a confidence score between 0 and 1, and a sentence explaining the judgement in plain language.
- Signal
- Which failure pattern matched, for example SILENT_FAILURE or MISSED_RUN.
- Evidence
- The observations behind the call: last run, expected cadence, item counts, terminal node, redacted error text.
- Confidence
- How sure the engine is, given how much history it had to work with.
- Reason
- One sentence you can forward to a colleague without translating it first.
What OutcomeGuard will not do
- It will not write to your workflows, change credentials, or alter billing and configuration on your behalf.
- It will not guess. If the instance is unreachable, the status is UNKNOWN until it can be reached again.
- It will not call something an anomaly on two data points. Statistical detections wait for enough history.
- Self-healing is limited to safe, reversible actions: retrying our own checks, re-sending a failed notification, re-running a verification.