How a finding is made
Every workflow is judged against its own baseline, which is learned from its own execution history. Nothing is compared against other workflows or other customers. A finding carries five things: the signal type, the evidence rows behind it, a timestamp, a confidence score between 0 and 1, and a one-sentence reason.
When a workflow has too few runs for a statistical judgement, OutcomeGuard reports insufficient data. That is a deliberate answer, not a gap: an anomaly called on two data points is noise, and noise is how monitoring gets switched off.
Hard failures
- FAILED
- An execution ended in error, crashed, or was cancelled. Evidence: the execution id, the failing node, and the redacted error message. Check the node named in the evidence first.
- AUTH_ERROR
- A credential was rejected — an expired OAuth token, a revoked API key, a changed password. Evidence includes the HTTP status where the connector exposed one. Re-authorise the credential in n8n.
- DOWNSTREAM_ERROR
- An external service the workflow depends on failed or refused the request. Often transient; repeated occurrences usually mean a quota, a deprecation or an IP restriction.
Quiet failures
- SILENT_FAILURE
- No error, and no work done. Raised when a trigger that used to fire regularly has gone quiet, or when successful runs start ending at an earlier node than usual. Compare the terminal node in the evidence with the node that is supposed to finish the job.
- MISSED_RUN
- A scheduled run did not happen. Cron and interval triggers are parsed with their timezone, and a grace period is applied before judging. Evidence shows the expected time and the actual last run. Check that the workflow is active and that its timezone matches the cron expression.
- EMPTY_OUTPUT
- The run succeeded and emitted zero items, on a workflow whose own history says items are normal. Walk the run and find the node where the count becomes zero — usually a filter, a query parameter or a changed field name.
- STALE_OUTPUT
- A downstream probe reports that the target has not changed for longer than the Outcome Contract allows. The workflow may be running perfectly and writing to the wrong place.
Statistical anomalies
- VOLUME_ANOMALY
- The number of runs, or the number of items per run, is far outside this workflow's normal range. Catches the half-empty import, which is harder to notice than the empty one.
- LATENCY_ANOMALY
- The run took far longer or far less time than normal. Far longer usually means a struggling dependency; far less usually means it carried nothing.
Both of these need enough history to have a meaningful range. Until then they are not raised at all, and the workflow appears in the insufficient-data list.
Configuration and availability
- CONFIG_DRIFT
- The workflow definition changed, or the workflow was deactivated. Evidence includes the previous and current definition hash and the active flag. Most “it used to work” incidents start here.
- OUTCOME_FAILED
- The workflow ran, but at least one rule in its Outcome Contract was not met. Evidence lists each failed rule with its own reason, so you can see whether it was the deadline, the item count, the runtime or the probe.
- UNKNOWN
- The instance could not be reached, so no judgement is made about its workflows. OutcomeGuard never converts silence into health.
Severity and automatic actions
Each signal carries a severity — info, warning or critical — and a remediation class that says how much OutcomeGuard is allowed to do on its own:
- AUTO_SAFE
- OutcomeGuard may act without asking: re-running its own check, re-sending a notification, re-running a verification.
- AUTO_WITH_GUARD
- An automatic action exists but only runs within limits, and never more than the configured number of attempts.
- DO_NOT_AUTO
- A human has to decide. OutcomeGuard reports and stops.
No remediation class allows OutcomeGuard to change your workflows, your credentials, or your configuration. That boundary does not move.