Skip to content

Your automation says “Success.” We verify the work actually happened.

OutcomeGuard watches your n8n workflows, learns what normal looks like for each one, and tells you when a run is missing, silent, empty, or only pretending to work.

Read-only n8n API access. Nothing to install inside your instance.

A green checkmark is not proof of work

n8n tells you whether an execution finished without throwing an error. It does not tell you whether the invoice was filed, the lead reached the CRM, or the report landed in the spreadsheet.

Most automation outages are quiet. A trigger stops firing. An IF branch starts matching zero items. A credential expires overnight. A source returns an empty list. Every execution still reads success — and nobody finds out until a customer asks where their data is.

  • Nothing ran

    A schedule trigger was switched off during an edit. The newest execution is four days old and still green.

  • It ran and did nothing

    A filter now matches zero items. The workflow succeeds in 800 ms and writes nothing, anywhere.

  • It ran and stopped early

    The run ends at the HTTP node instead of the database node. No error, no data, no alert.

Know your automation broke before your customer does.

One email per incident, with the evidence attached: what we expected, what we saw, when we saw it, and how sure we are.

What OutcomeGuard looks for

Findings are judged per workflow, against that workflow's own history — never against other customers. Each one carries the signal, the evidence, a timestamp, a confidence score and a plain reason. When there is not enough history to judge, OutcomeGuard reports insufficient data instead of inventing an anomaly.

  • Silent failureSILENT_FAILURE

    No error, and still no work done: the trigger has gone quiet, or successful runs now stop at an earlier node than they used to.

  • Missed runMISSED_RUN

    A scheduled run did not happen. Cron and interval triggers are read with their timezone, so a 08:30 JST run is judged at 08:30 JST.

  • Empty outputEMPTY_OUTPUT

    The run succeeded but emitted zero items, where this workflow's own history says items are normal.

  • FailedFAILED

    An execution ended in an error, a crash or a cancellation.

  • Outcome not metOUTCOME_FAILED

    The workflow ran, but at least one condition in its Outcome Contract was not met.

  • Stale outputSTALE_OUTPUT

    The target of the workflow has not changed for longer than the Outcome Contract allows.

  • Volume anomalyVOLUME_ANOMALY

    The number of runs, or the number of items per run, is far outside this workflow's normal range.

  • Latency anomalyLATENCY_ANOMALY

    The run took far longer or far less time than this workflow normally takes.

  • Authentication errorAUTH_ERROR

    A credential was rejected — an expired OAuth token, a revoked key, a changed password.

  • Downstream errorDOWNSTREAM_ERROR

    An external service the workflow depends on failed or refused the request.

  • Configuration driftCONFIG_DRIFT

    The workflow definition changed, or the workflow was deactivated.

  • UnknownUNKNOWN

    The instance could not be reached, so nothing is being claimed about this workflow. We never guess.

Outcome Contracts: write down what “done” means

Execution monitoring answers did it run and did it error. An Outcome Contract answers did the job get done.

For each workflow you state the result you expect. OutcomeGuard checks every condition once the deadline has passed, and the workflow counts as healthy only when all of them hold.

An example contract

Healthy
  1. Every weekday after 08:30 JST the workflow must run
  2. the execution must succeed
  3. it must output at least 1 item
  4. it must finish in under 5 minutes
  5. and a downstream probe must confirm that the target was updated.

If any one of those is false, the workflow is not healthy — even if n8n recorded a success.

From API key to first finding

  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.

Heartbeats and Error Workflows only see hard failures

A heartbeat tells you that a process pinged. An n8n Error Workflow fires when a node throws. Both are useful, and both stay quiet for the failures that cost the most: the run that never started, the run that returned nothing, the run that stopped one node early.

OutcomeGuard learns each workflow's own cadence, duration, item count and usual terminal node from its execution history, then judges new runs against that baseline and against the schedule the trigger actually declares.

Deliberately boring about your data

  • Read-only access through the n8n public REST API. OutcomeGuard never writes to your workflows.
  • We store execution summaries — status, timestamps, duration, item counts, last node, redacted error text — never raw execution payloads.
  • Your API key is encrypted at rest with AES-256-GCM, with keys held only in the runtime environment.
  • Automatic actions are limited to safe ones: retrying our own checks and re-sending a notification. We never rewrite a workflow or touch a credential.

n8n first

Version 1 covers n8n, self-hosted and n8n Cloud. Make, Zapier and GitHub Actions are on the roadmap; we would rather do one platform properly than four badly.

Roadmap

Introductory pricing

Free for 3 workflows, no card. Paid plans from $19 a month, billed monthly, cancel any time.

Find out what is quietly broken right now

Paste your n8n URL and an API key. The scan is read-only, takes about a minute, and the key is discarded when it finishes unless you choose to connect the instance.

Read-only. No card required.