Reliability

Overview

Reliability measures whether a workflow keeps producing correct results under real production conditions: retries, partial failures, malformed data, duplicate events. It's the category most directly tied to incidents — a broken retry or an unguarded branch is what usually turns "the workflow ran" into "the workflow ran and did the wrong thing."

How this affects your score

Reliability is weighted 0.35 — more than double any other category, and more than a third of the total score on its own. A clean Reliability score with problems everywhere else still pulls the total up meaningfully; a poor Reliability score with everything else clean still pulls it down hard.

Two of FlowScan's three hard score caps involve this category directly:

• Retry without idempotency next to a financial write caps Reliability at 50, no matter what else in the category looks clean.
• A partially-guarded write chain next to a financial write caps the overall total at 50 — this cap applies to the total score, not just Reliability, because a half-protected write chain is treated as a workflow-wide risk rather than a category-local one.

Worked example: a workflow with one critical finding (a partial write chain, no financial write present so no cap triggers) and one medium finding (an IF branch with no default path) scores 100 − 30 − 8 = 62 on Reliability, contributing 62 × 0.35 = 21.7 points toward the total.

Findings

Error handling & recovery

Severity: medium → critical. This sub-theme covers whether the workflow notices failure and stops safely instead of continuing on a false assumption.

• No error workflow attached. Nothing catches a failed execution — it simply stops, and nobody is notified. Example: a workflow updates a CRM record and has no error workflow configured; when the CRM API returns a 500, the execution fails silently and the record is never retried or flagged. Fix: attach a dedicated error workflow under Workflow Settings that routes failures to a channel someone actually watches.
• An external call with no timeout. A hung request can block execution indefinitely. Example: an HTTP node calling a third-party API with no timeout set stalls when that API is slow to respond, holding up everything downstream. Fix: set an explicit timeout on every external call, short enough that a hang is caught before it becomes a bigger problem.
• Missing credentials. A node is configured to run but points at a credential that doesn't exist or has been revoked. Example: a Slack node references a bot token that was rotated out three weeks ago; the workflow fails on its next run and nobody connects the failure to the rotation. Fix: audit credential references whenever a token is rotated, and alert on authentication failures specifically rather than treating them as generic errors.
• continueOnFail on a write step. Fine on a read, dangerous on a write — a failed database update or API call is treated as a success and the workflow proceeds as if nothing happened. Example: a node writes an invoice record with continueOnFail enabled; the write fails due to a schema mismatch, but the workflow continues and sends a "invoice created" notification anyway. Fix: remove continueOnFail from write steps, or replace it with explicit error-branch handling that treats a failed write as a failed write.
• An error workflow that references itself. The error handler for a workflow is the workflow itself, so an error can trigger another execution that errors again. Fix: point the error workflow setting at a separate, dedicated error-handling workflow.
• A safeguard node disabled on a live path. A validation or error-handling node was turned off during debugging and never re-enabled. Fix: review disabled nodes on any workflow before it goes back into production use.

Idempotency & duplicate writes

Severity: medium → critical. Networks retry, and webhooks fire more than once. This sub-theme covers whether a write is safe to run twice.

• Retry with no way to detect "already done." A step retries on failure, but nothing checks whether the first attempt actually succeeded before retrying. Example: a payment-charge node retries on timeout; the first attempt actually succeeded but the response was slow, so the retry charges the customer a second time. Fix: generate an idempotency key per logical operation and check it before retrying, or pass the key to the downstream API if it supports one natively.
• No de-dupe before a write. Nothing checks whether this exact record has already been written. Fix: look up the target record by a stable identifier before writing, and skip or update instead of blindly inserting.
• A webhook with no de-dupe guard. The same delivery can arrive more than once from the sender's own retry logic. Example: a Stripe webhook is configured without checking the event ID against previously processed events; a delivery retry (which Stripe does automatically) processes the same event twice. Fix: store processed event IDs and short-circuit on a repeat before continuing.
• A partially-guarded write chain. Some steps in a multi-step write have duplicate protection; others don't — this is the pattern behind one of the hard score caps described above.

Data flow & branching integrity

Severity: low → high. A workflow can run without a single execution error and still produce wrong results, because the shape of the data was never validated.

• An IF/Switch branch with no default or else path. Anything that doesn't match the conditions considered falls off the workflow with no record. Fix: add an explicit default branch that at minimum logs the unmatched case.
• A merge node combining misaligned data before a write. If two branches don't line up item-for-item, the merge writes incorrect combinations. Fix: verify alignment (by a shared key, not just position) before merging branches that feed a write.
• Unhandled pagination. Only the first page of results is processed; the gap isn't noticed until the dataset grows past one page. Fix: handle pagination explicitly, or use a node/operation that paginates automatically.
• AI output feeding a write with no structured-output parser. The model's response is free text, trusted to also be valid, correctly-shaped data. Example: an AI node extracts fields from an email and passes the raw text response directly into a "create record" node; a slightly reworded model response breaks the downstream field mapping. Fix: add a structured-output parser between the AI call and the write so malformed responses fail loudly instead of writing bad data.
• Fragile expressions feeding a write, AI call, or condition. Deep property chains, raw $json references, or missing null checks — one unexpected input shape and the expression throws or silently evaluates wrong. Fix: add null checks and prefer named field references over deep chained lookups.

Chain & fan-out failure risk

Severity: medium → critical. Individual nodes can be correct and the shape of the workflow can still be the problem.

• Nested loops with something expensive or risky inside. Cost and risk both multiply by iteration count, compounded by nesting depth.
• A webhook responding synchronously while doing slow AI work. The caller times out waiting for a response that was never going to arrive in time, and may retry (see idempotency, above).
• An HTTP response sent before a write actually completes. The caller believes the operation succeeded before it's confirmed.
• A code node making hidden external calls. Nothing else in the workflow is aware this call exists, because it's buried inside a script — timeouts and retries configured elsewhere don't apply to it.
• Wide fan-out with no error handling. Three or more branches running off one trigger, none protected — one failure and there's no clear picture of what did or didn't complete.
• Many results converging into one node (fan-in overload). A node reconciling results from a large number of parallel branches is a natural bottleneck.
• Long serial chains of external calls. Each call's latency stacks on the next — a timeout cascade waiting to happen.
• A node reference pointing to something deleted or disabled. Fails the moment execution reaches it.
• A deprecated AI model in use. Works today; may be pulled without much notice.

Structural hygiene

Severity: info → medium. Lower stakes individually, but cheap to fix and worth clearing.

• Orphaned or isolated nodes — configured but not connected to anything, usually leftover from an earlier version of the workflow.
• Unreachable ("dead") nodes — connected, but nothing upstream can reach them.
• Duplicate HTTP calls to the same static URL — redundant work and a second independent failure point.
• A read-only external call with no retry — lower stakes than a write without retry; informational.

Make.com parity

Severity: medium → critical. If you're on Make rather than n8n, the equivalent checks — expression fragility, writes without dedupe, retries without idempotency, partial write chains — run against Make's scenario structure instead of n8n's. The underlying question doesn't change between platforms: if this runs twice, or receives unexpected data, does it fail safely?

Recommended fixes

In priority order, based on where the score impact and production blast radius are both highest:

1. Fix any retry-without-idempotency or partial-write-chain finding that sits near a financial write first — these are the two hard-cap triggers, and they're also the patterns most likely to correspond to a real customer-facing incident.
2. Attach an error workflow if one isn't present, and confirm it doesn't reference itself.
3. Add default/else branches to conditional logic that feeds a write.
4. Add timeouts to any external call that doesn't have one.
5. Clear structural hygiene findings (orphaned nodes, dead nodes, duplicate calls) — low effort, and they make the workflow easier to review for everything above.

Related categories

• Cost Risk — several chain and loop failure patterns here are also cost multipliers
• Observability — knowing a reliability failure happened is a separate finding from preventing it
• Security — an unauthenticated webhook with no de-dupe guard is both a reliability and a security gap