D2 Automation Knowledge
Production n8n Readiness Checklist
A workflow is production-ready when duplicate events, partial failure, retries, state, load, credentials, monitoring and recovery are designed deliberately—not when the happy path merely runs once.
Release gate 01
Ownership, business impact and event identity
Before implementation details, define what must remain true for the business when the workflow succeeds, fails, is delayed or receives the same event twice.
- A named business owner and technical/operational owner exist.
- Critical side effects such as emails, orders, CRM writes or inventory changes are identified.
- The trigger source and retry/redelivery behavior are understood.
- Stable event or business identifiers are used where the source provides them.
- Manual replay cannot silently repeat irreversible side effects.
- A fallback or escalation path exists for business-critical processes.
Release gate 02
Validation, idempotency, durable state and checkpoints
Retries are only safe when the workflow knows what happened already. Durable state should represent the business process, not merely an execution ID.
- Required fields and unsupported states are validated before business logic runs.
- Authentication or signature checks are used when the source supports them.
- Duplicate-sensitive actions use a stable event key or business identifier.
- Processed-event or state records survive workflow and instance restarts where necessary.
- Partial completion can be distinguished from full completion.
- A failed run can resume or restart without guessing which side effects already happened.
Release gate 03
Bounded retries, concurrency and backpressure
Production automation has to respect downstream limits even when n8n itself can accept more work.
- Transient failures are separated from permanent validation or business failures.
- Retries are bounded and use appropriate delay/backoff where dependencies can be rate-limited.
- Expected and peak event volume are understood.
- Burst behavior is tested, not only one execution at a time.
- Concurrency is controlled where parallel runs can race on the same records.
- Database and external API capacity are treated as real system limits.
Release gate 04
Error handling, observability and silent-failure detection
A technically green execution can still produce the wrong business outcome. Monitoring should cover both workflow health and expected business outputs.
- Expected API/node failures have an explicit branch, retry rule or failure state.
- Critical workflows use a centralized error path where appropriate.
- Operators can review success/failure volume without opening every execution manually.
- Alerts are reserved for actionable failures or thresholds.
- Event/business ID, execution ID, status and timestamps are available for diagnosis.
- Monitoring can detect when expected events or business outputs unexpectedly stop arriving.
Release gate 05
Credentials, deployment, recovery and handover
Production readiness includes change control and operating ownership after launch.
- Credentials are not hard-coded into workflow logic and test/production access is separated where relevant.
- High-impact changes are tested with representative payloads before activation.
- Replacing a workflow cannot leave old and new versions producing duplicate side effects.
- A rollback, disable or temporary fallback path exists for material changes.
- The runbook explains when to retry, replay, resume, correct data manually or stop automation.
- Purpose, dependencies, assumptions, limits and maintenance ownership are documented.
Final release decision
Four questions every critical workflow should answer
- 1.How do we know an event was processed exactly as intended?
- 2.What happens when the same event arrives twice or a step is retried?
- 3.How will we know the workflow is unhealthy or silently missing business output?
- 4.How do we recover without repeating completed side effects?
Production review