Production Reliability Shield Pro — n8n Workflow Template
Headline n8n Production Reliability Shield Pro — Atomic Idempotency, Duplicate Detection, Semantic Checks & Test Runner Subhead Stop duplicate webhook deliveries from creating duplicate business actions. Detect empty-success runs immediately after they happen — before dependent steps act on bad data. Prove your reliability layer works with a built-in test runner. The problem n8n tells you a workflow ran successfully. But "ran successfully" means n8n executed without throwing an error — it does not mean: The webhook wasn't delivered twice (and your order wasn't created twice) The CRM update actually wrote a record (not zero records) The email went to the right contact (not an empty list) The payment charge happened once (not in duplicate) These are the failures that don't raise exceptions. They show up as duplicate orders in your fulfillment system, phantom charges in your billing, ghost contacts in your CRM, or silent no-ops where your automation technically ran but nothing happened. The n8n Production Reliability Shield is a reusable sub-workflow you call from your existing workflows: it blocks duplicates and stale or malformed events before your downstream action runs, and verifies immediately after each run that the work actually happened — flagging empty-success and semantic failures before dependent steps act on them. What you get 3 workflow files: workflow.pro.shield.json — the main Shield sub-workflow (25 functional nodes plus 5 sticky-note annotations; import once, call from anywhere) workflow.pro.test-runner.json — built-in test runner that verifies 20/20 detection scenarios workflow.lite.json — Lite demo for evaluation (n8n staticData store, no Postgres required) 9 SQL files: sql/schema.sql — portable Postgres 14+ schema (two tables with supporting indexes) sql/schema_supabase_rls.sql — optional Supabase Row-Level Security (idempotent, run after schema.sql) sql/idempotency_check.sql — the atomic INSERT ON CONFLICT query sql/finalize_decision.sql, sql/finalize_post_action.sql — two-phase finalization sql/fuzzy_lookup.sql, sql/ordering_lookup.sql, sql/semantic_lookup.sql sql/cleanup.sql — daily TTL expiry and stale-pending flagging 10 source files (src/): config_defaults.js, canonicalize.js, redact.js, fuzzy.js, ordering.js, semantic.js, quarantine.js, normalize.js, lite_engine.js, test_cases.js 5 documentation files (docs/): SETUP_GUIDE.md — step-by-step setup with troubleshooting CONFIG_REFERENCE.md — every config field with type, defaults, examples, and 4 use-case configs RELIABILITY_MODEL.md — honest explanation of what is and is not guaranteed TEST_PLAN.md — all 23 test scenarios with diagnosis steps LIMITATIONS.md — 11 documented boundaries of the system Plus: DESIGN.md (architecture decisions and rationale), CHANGELOG.md (v1 scope, live-test scope, and the v1.1 roadmap), and tests/test_logic.js — a standalone local test suite (runs with plain node, no n8n or Postgres required) covering the decision logic and workflow structure. How it works [Your Trigger] ↓ [Shield: pre_action] ← atomic Postgres check ↓ [If: safe_to_continue] → yes: [Your Business Action] → [Shield: post_action] ← semantic check → no: [Handle gracefully — skip / log / alert] The shield runs in two stages: Stage 1 — pre_action (before your action): Computes an idempotency key from your configured fields Executes an atomic Postgres INSERT ON CONFLICT — one SQL statement, no separate read If new: runs fuzzy near-duplicate detection, ordering check, staleness check Returns a decision: process, duplicate, quarantine, out_of_order, stale, or error Stage 2 — post_action (after your action): Looks up the idempotency row created by pre_action Runs semantic assertions on your downstream output (output count, required fields, status values) Returns process (semantically valid) or semantic_failure One sub-workflow. Call it from as many production workflows as you want. What it proves The built-in test runner executes 20 scenarios against the live shield and reports pass/fail: Fresh valid event → process Exact duplicate (3 re-deliveries) → duplicate Same business event, new delivery ID → duplicate Fuzzy near-duplicate (88% similarity, score asserted in [0.85, 0.999]) → quarantine Out-of-order sequence (seq 5 after seq 7) → out_of_order Stale event (120 min old, 60 min window) → stale Missing required field → error Payload with sensitive fields → process with redacted preview (runner asserts [REDACTED] present and raw PII strings absent) Empty-success run (0 outputs, min 2) → semantic_failure Required field missing from output → semantic_failure Forbidden empty field in output → semantic_failure Unexpected status value in output → semantic_failure Run the test runner before deploying to production. All 20 must pass. If any fail, the runner tells you which scenario failed and what it got vs. what it expected. All 20 scenarios were live-tested against a real n8n + Postgres deployment before release (20/20 passing). External alert/audit integrations (Telegram, email, Google Sheets) are not included in v1 — they are planned for v1.1 after credentialed live testing. In v1, Postgres is your audit record: it stores one row per unique event key in reliability_events, updates delivery_count on repeat deliveries, and stores held events in reliability_quarantine. Some validation errors can be returned before a database row is created. What it does NOT claim This section exists because a reliability tool that overstates its guarantees is actively dangerous. The shield does not guarantee exactly-once execution end-to-end. It guarantees that two concurrent Postgres writes for the same idempotency key cannot both return is_new=true. It cannot guarantee that your downstream action (the code that runs after safe_to_continue=true) executes exactly once. If n8n crashes after the idempotency check passes but before your action completes, the action was partially executed and the duplicate protection prevents re-execution on retry. The shield does not replace n8n queue mode. It adds idempotency and semantic checks. It does not handle backpressure, worker scaling, or distributed coordination. The fuzzy check is trigram similarity, not semantic AI. It detects character-level near-duplicates. It does not understand meaning, language, or business context. The shield does not send external alerts or export audit rows in v1. External alert/audit integrations (Telegram, email, Google Sheets) are planned for v1.1 after credentialed live testing. In v1, monitoring comes from the Postgres tables and the logging_error/reason_codes fields in the shield's response. Supabase REST does not preserve the same atomicity guarantee as direct Postgres. If you use Supabase REST endpoints instead of a direct connection, the xmax=0 new-row detection does not work. The setup guide documents an alternative approach with a caveat about the weaker guarantee. Quarantined events are not auto-replayed. Manual review only. The quarantine table is a hold queue. FAQ 1. Does this work on n8n Cloud? Yes. For the Postgres requirement, use Supabase (free tier works for most volumes) or any hosted Postgres provider (Neon, Railway). The setup guide covers both direct Postgres and Supabase. Note the Supabase REST atomicity caveat in the docs if you can't use a direct Postgres connection from n8n Cloud. 2. Does this replace my Error Workflow? No — they are complementary. n8n's Error Workflow fires when a node throws an unhandled exception. The shield catches business-logic failures that don't throw exceptions: duplicate events, empty outputs, missing fields, unexpected status values. Use both. 3. Do I need Supabase specifically? No. Any Postgres 14+ database works: self-hosted, Railway, Neon, Supabase, AWS RDS, DigitalOcean Managed Postgres. The SQL uses only standard Postgres syntax. The Supabase RLS file is provided as an optional add-on for Supabase users. 4. What happens if Postgres goes down? Depends on your fail_mode config: fail_closed (default) — shield returns error, safe_to_continue=false. Your caller does not proceed, so the shield does not introduce duplicate processing while Postgres is down — provided your caller honors safe_to_continue. Events must be replayed after recovery. fail_open_for_logging_only — shield returns process, safe_to_continue=true. Your caller proceeds. Duplicates are possible during the outage. In both modes the response carries logging_error: true and the failure reason codes, so your caller can detect the outage. 5. Can I use this with multiple workflows? Yes — that's the intended pattern. Import the shield once, then call it as a sub-workflow from any number of production workflows using n8n's Execute Workflow node. Each calling workflow sends its own source, entity_type, and entity_id values. The idempotency namespace is naturally partitioned by these fields. 6. What volume can it handle? Idempotency uses a single Postgres INSERT ON CONFLICT per event, so concurrency safety comes from Postgres itself. No formal throughput benchmark has been run — the shipped test suite verifies correctness (20 live scenarios), not load. Each shield call is a handful of single-statement Postgres queries, so throughput scales with your Postgres instance. For high-throughput deployments, size your Postgres accordingly and use a dedicated monitoring stack on the reliability_events table. 7. What about GDPR and PII? Every payload-derived field the shield persists is run through redaction before storage. canonical_preview (stored in the database), metadata_json (the fuzzy-comparison copy of your configured fuzzy_fields), and safe_metadata (the quarantine review copy — the same redacted fuzzy-fields metadata) all go through field-level redaction for named sensitive fields (password, SSN, card number, token, etc.) plus regex-based pattern redaction. The default regex patterns cover SSN, card-number, and email-address formats — they do not detect person names, phone numbers, or street addresses; add your own redact_fields entries or redact_patterns regexes for those or any business-specific identifiers. entity_id and business identifiers (source, entity_type, action_name) are stored as-is for querying. If you use PII as entity identifiers (e.g., email as customer ID), hash or pseudonymize before passing to the shield. The full list of stored fields is documented in the setup guide's PII section. Pricing Launch price: $49 — use coupon EARLYBIRD for 15% off. Standard price after first sales: $79. Full documentation included. Questions? Reply to this listing.
Get it → mdebrand.gumroad.com