A green n8n execution proves that the path which ran did not throw an error.
It does not prove that:
- the trigger fired when it should;
- the event was processed only once;
- every required branch produced an explicit terminal outcome;
- a timed-out side effect is safe to reconcile before retry;
- the output was complete and fresh;
- a valid-looking value came from the intended source;
- approval came from a trusted source;
- a recovery operator can explain what happened.
That distinction matters because some production failures create no failed execution at all. In a recent n8n Community report, scheduled workflows silently stopped firing and no failed executions appeared because no execution was created. Other recent threads describe webhook retries producing duplicate inserts, API calls, and emails even though each individual run looks legitimate.
This is the checklist I now use before calling an n8n workflow reliable.
Run the free browser-only 60-second version →
It asks for no email, credentials, workflow JSON, or customer data. Your eleven answers stay in the browser.
1. Did the expected execution start?
The execution log cannot report a trigger that never created an execution.
Define a heartbeat contract outside the happy path:
expected interval: 15 minutes
last seen: 2026-07-19T04:30:00Z
alert after: 20 minutes
owner: operations
For a scheduled workflow, “no failed run” is not enough. You also need evidence that a run was expected and observed.
Recent community examples show why this matters:
- Schedule Trigger silently stops firing in Kubernetes queue mode
- Scheduled jobs stopped with no useful execution error
These are individual reports, not proof that every n8n scheduler is unreliable. They are proof that a heartbeat belongs in the contract.
2. Is replay ownership durable?
Generating an idempotency key is not duplicate protection.
The workflow needs a durable system that decides which execution owns the side effect. Under concurrency, the decision must be atomic.
For PostgreSQL, the shape can be as small as:
INSERT INTO processed_events (event_id)
VALUES ($1)
ON CONFLICT DO NOTHING
RETURNING event_id;
One execution receives the returned row and continues. The duplicate receives nothing and produces a replay receipt.
3. Have you tested two simultaneous deliveries?
A lookup followed by a later write can still race:
execution A: lookup → missing
execution B: lookup → missing
execution A: send email
execution B: send email
Run the duplicate case concurrently, not one retry after another. The acceptance result should be one protected side effect, one replay decision, and two explainable receipts.
The pattern appears repeatedly in current webhook discussions, including duplicate executions caused by provider retries.
4. Does every required zero-item branch produce a receipt?
An empty branch can sit inside an execution labelled successful. That may be valid routing behavior, but a required branch must not disappear silently.
Define the empty outcome explicitly:
expected branch: qualified-lead
items received: 0
terminal state: skipped | rejected | failed
reason: stored and queryable
A recent community question describes a workflow reporting success while a Switch path had no output data. The contract is not “every branch must emit an item.” It is “every required branch must reach an explainable terminal state.”
5. Can an ambiguous side effect be reconciled before retry?
A remote system can commit a write and then time out before n8n receives the response. Blindly retrying can duplicate the action even when the original execution appears failed.
For irreversible actions, store an idempotency key and reconcile it against the destination before retry:
attempt: request sent
response: timeout
destination lookup by idempotency key: committed
decision: record prior success, do not repeat
The acceptance case must simulate “committed remotely, failed locally,” not only a clean pre-write failure.
6. Does the output match an explicit schema?
“The node returned JSON” is not a contract.
Check required fields, types, allowed values, and forbidden authority fields before the next side effect. This is especially important when an AI node can return valid JSON with missing or semantically wrong content.
{
"required": ["eventId", "decision", "completedAt"],
"decision": ["accepted", "rejected", "replay", "failed"]
}
Schema validation catches malformed output. It does not prove that a well-formed value came from the correct record.
7. Is the value mapped from the intended source?
Two records can share the same field names and valid types. A workflow can therefore pass schema checks while writing the wrong customer's value.
Add provenance to the acceptance evidence:
target customer id: customer-42
selected source id: customer-42
source field: billing.email
collision fixture: customer-24 has the same field shape
The test passes only when the correct source identity survives into the receipt. “The email field exists” is not enough.
8. Is the context fresh enough?
Define how old an input may be.
Examples:
- a lead score may be valid for 24 hours;
- inventory might be valid for 60 seconds;
- an approval response may expire after one business day.
Without a freshness rule, a technically valid result can be operationally wrong.
9. Can public input approve itself?
Do not trust fields such as approved: true, reviewer, or role when they arrive from a public webhook.
Strip them at the boundary. Re-create authority only from a trusted review channel or system-owned state. Preserve reviewer alias, channel, and response time in the final receipt.
Missing review evidence must fail closed. “No evidence” must not silently become “approved.”
10. Does every accepted event reach a terminal receipt?
Every event that crosses the intake boundary should end as one of:
accepted
rejected
replay
failed
The receipt should include the contract version, replay decision, output summary, review evidence when applicable, and recovery action.
Without a terminal receipt, you cannot distinguish “still processing” from “silently disappeared.”
11. Can you rehearse recovery without repeating the side effect?
Use synthetic data to fail the workflow after the protected action, then replay it.
The recovery test passes only when:
- the side effect is not repeated;
- the replay decision is visible;
- the final receipt explains the prior action;
- no production credential or customer record is required for the test.
Turn the checklist into an acceptance matrix
For each control, record:
case
input condition
expected decision
expected side-effect count
expected receipt
recovery action
Do not accept “works” as the expected result.
Builderlog's free Reliability Contract Pack v2.3 contains an inspectable three-workflow reference, atomic replay SQL, evaluation fixtures, 11 workflow/topology cases, and a zero-dependency verifier. Its current stored receipt matches 41/41 structural checks and 11/11 cases. That proves the packet's deterministic expectations and integrity, not a buyer production outcome.
If the 60-second audit exposes missing controls, the current Production Reliability Kit Pro.4 is $19 for buyer #1. It adds the scope workbook, topology questionnaire, fourteen-case starter matrix, semantic source-mapping checks, empty-branch receipts, ambiguous-retry reconciliation, incident/replay receipts, a handoff checklist, and a second verifier.
If you want the gaps prioritized against one sanitized workflow rather than adapting the contracts yourself, the written workflow review is $49: three priority findings and one acceptance test within 24 hours, with the purchase price credited toward the $299 fix or $799 sprint for seven days.
Run the private 11-check audit first →
No password, API key, workflow export, email, or customer data is required.
Top comments (0)