n8n Production Checklist: 15 Checks Before Go-Live

An n8n production checklist should answer a harder question than "did the workflow run once?" It should prove the workflow can fail safely, avoid duplicates, protect credentials, alert the right person and be handed over without guesswork.

A workflow can look finished on the canvas and still be unsafe to run. The dangerous problems usually appear after launch: a webhook fires twice, an API times out after creating a record, a retry creates a duplicate invoice, a credential expires silently, or the person who built it is the only person who knows how to stop it.

The short version: do not approve an n8n workflow for production until it has a named owner, duplicate protection, tested failure paths, useful alerts, a safe retry method, destination readback and a documented off switch.

The n8n production checklist at a glance

1. Define the workflow owner and production outcome.
2. Document the trigger and expected volume.
3. Separate test data from live data.
4. Protect against duplicate triggers and duplicate writes.
5. Make retries safe.
6. Handle expected exceptions inside the workflow.
7. Route unexpected failures to a useful alert.
8. Require human approval for high-impact actions.
9. Test realistic edge cases, not just the happy path.
10. Read back the destination after important writes.
11. Review credentials, permissions and exposed webhooks.
12. Set execution-data and privacy rules.
13. Control changes between development and production.
14. Prepare rollback, pause and recovery steps.
15. Hand over the workflow with a runbook.

1. Define the owner and the production outcome

Every production workflow needs one business owner and one technical owner. The business owner decides whether the result is correct. The technical owner handles failures, credentials and changes.

Write the production outcome in plain language. For example: "When a paid invoice appears in Xero, update the matching HubSpot deal once and record the Xero invoice ID." That is testable. "Keep the CRM in sync" is not.

Also define what the workflow must never do. A useful n8n production checklist includes explicit boundaries such as no automatic payment, no deletion, no customer email without approval, or no update when the source record is ambiguous.

2. Document the trigger and expected volume

Know exactly what starts the workflow: webhook, schedule, form submission, inbox event, database change or another workflow. Then record the normal and worst-case event volume.

This matters because a workflow that handles five events in testing may behave differently when 500 arrive together. Look for API rate limits, pagination, concurrency, long-running executions and downstream systems that accept requests more slowly than n8n can send them.

3. Separate test data from live data

Production testing should not rely on remembering which customer, invoice or folder is safe. Use a test tenant, sandbox, marked test record or tightly controlled test path where the connected platform allows it.

If the workflow is commercially important, separate development and production. n8n documents source-control and environment patterns that can add a review boundary before changes reach production. Some environment features depend on the n8n plan, so the practical setup may instead use separate instances, separate credentials and a documented promotion process.

Source: n8n source control and environments documentation.

4. Protect against duplicate triggers and writes

Assume important triggers can arrive twice. Webhook providers retry. Staff click submit again. Scheduled workflows overlap. A timeout can occur after the destination accepted the write but before n8n received the response.

Use a stable idempotency key where the destination supports one. Otherwise, check for the exact source ID or business reference before creating anything. For multi-step writes, keep a small processing ledger with the source event, destination ID and outcome.

Do not use a fuzzy search as the only duplicate check for invoices, contacts, claims or payments. The match rule should be deterministic and explainable.

5. Make retries safe

A retry is only safe when repeating the step cannot create a second real-world action. Read-only requests are usually straightforward. Record creation, email, payment, claim submission and file movement need more care.

Before enabling automatic retries, answer:

• Can the request be repeated without creating another record?
• Can the workflow check whether the first attempt succeeded?
• Does the external API support an idempotency key?
• Will the retry use the same source snapshot?
• Who reviews an uncertain outcome?

n8n lets authorised users retry failed executions with either the original workflow or the currently saved workflow. That is useful for recovery, but the business action still needs to be safe to repeat.

Source: n8n execution and retry documentation.

6. Handle expected exceptions inside the workflow

Not every exception is a system failure. A missing customer ID, unmatched invoice, invalid date or ambiguous document may be a normal business exception.

Route these cases to a review queue with the source record, reason, timestamp and next action. Do not let an unresolved item disappear into a generic failed-execution list. The person reviewing it should not need to open the workflow canvas to understand the problem.

7. Send useful alerts for unexpected failures

An alert that says "workflow failed" is barely useful. A production alert should contain:

• Workflow name and environment.
• Execution link or run ID.
• Source record or business reference.
• Failed step and a safe error summary.
• Whether any earlier write succeeded.
• The required owner and next action.

Keep secrets and sensitive payloads out of chat or email alerts. Link authorised staff to the execution record instead.

8. Keep humans on high-impact actions

Some actions should stop for approval even when the automation is technically capable of continuing. Payments, claims, customer communications, record deletion, legal decisions and changes to a system of record deserve a clear approval boundary.

The workflow should preserve the exact item being approved. If the underlying record changes after the review request is generated, the old approval should not silently authorise the new version.

9. Test the edge cases deliberately

A useful n8n production checklist includes a written test matrix. At minimum, test:

• A valid normal event.
• A duplicate event.
• A missing required field.
• An invalid date or number.
• No matching destination record.
• Multiple possible destination matches.
• An expired or revoked credential.
• A downstream API error.
• A partial success followed by failure.
• A replay of the same source event.

For time-sensitive workflows, also test the real Australian timezone, daylight-saving boundaries where relevant, public holidays and events that arrive just before or after a scheduled cutoff.

10. Read back important destination writes

A successful HTTP status proves the destination accepted a request. It does not always prove the record now contains the intended values.

For important writes, read the record back and verify its ID, status, amount, line items, owner or destination folder. This catches transformations, defaults and platform behaviour that a green node cannot reveal.

11. Review credentials, permissions and webhooks

Use the narrowest practical permissions. Separate production credentials from testing credentials. Know who owns each connection and what happens when that person leaves or changes a password.

Self-hosted n8n includes a security audit available through the CLI, API or n8n node. The audit can identify issues such as unprotected webhooks, outdated instances, community nodes, risky built-in nodes and credential concerns. It is a useful check, not a complete security review.

Source: n8n security audit documentation.

12. Set execution-data and privacy rules

Execution logs can contain customer details, document contents, access URLs and other sensitive data. Decide what must be retained for support and audit, what should be excluded, and how long execution data should remain available.

Use representative synthetic data for routine testing where possible. Do not paste production credentials or personal information into support messages, screenshots or public workflow examples. If the workflow decides something about a person, add it to your automated decision making inventory as well.

13. Control production changes

Record the live workflow version, deployment date and change reason. Important changes should be reviewed against the same n8n production checklist as the original launch.

Do not edit a critical live workflow without a recovery path. Export a known-good version, preserve the configuration needed to restore it, and confirm which credentials or variables are not included in the export.

14. Prepare the off switch and recovery path

The owner should know how to pause the workflow safely. Document what happens to events that arrive while it is paused, how they will be recovered, and how to prevent a backlog from creating a burst of duplicate or outdated actions when the workflow resumes.

For a multi-step process, document partial-write recovery. If step three fails after steps one and two succeed, the response may be to continue, reverse, reconcile or hold for review. "Run it again" is not a recovery plan.

15. Hand over the workflow with a runbook

A production workflow is not complete until someone other than the builder can operate it. The handover should include:

• Purpose, owner and expected schedule or volume.
• Systems, credentials and permission owners.
• Trigger, main path and exception paths.
• Alert destinations and response steps.
• Duplicate and retry controls.
• How to pause, resume and recover.
• Known limitations and actions that stay human.
• A recorded walkthrough and current workflow export.

Running an n8n security audit: what to check

n8n has its own security audit built in for self-hosted instances. Run it before go-live, after any big change and on a regular schedule. It's the quickest way to see the obvious risks, and there's nothing extra to install.

There are three ways to start it. From the command line, run n8n audit. Through the public API, send a POST request to the /audit endpoint, logged in as the instance owner. Or add the n8n node to a workflow and pick Resource: Audit, Operation: Generate. The node option is handy because you can put it on a schedule and send the report to someone who will actually read it.

The report is split into five risk areas. Here's what each one flags and what we'd do about it.

What the n8n security audit won't tell you

The audit only sees what n8n can see from the inside. It won't show you:

• Whether an API key or OAuth connection has far more access than the workflow needs. That's set in the other system.
• Who holds owner or admin accounts, and whether they use two-factor authentication.
• Whether the n8n editor is open to the public internet.
• Whether someone pasted a token straight into an HTTP Request header or a Code node instead of saving it as a credential.
• What customer data is sitting in old execution logs.
• Whether your backups and encryption key would actually let you restore the instance.

So treat the audit as the first pass, then check those six by hand. n8n's security docs cover the settings that close most of the gaps: SSL, single sign-on, two-factor authentication, encryption key rotation, execution data redaction, turning off the public API, blocking specific nodes and SSRF protection.

Sources: n8n security audit documentation and securing a self-hosted n8n instance.

Keeping up with n8n security advisories and CVEs

n8n publishes its security advisories on GitHub, in the security tab of the n8n-io/n8n repository. Each one names the issue, gives a severity rating and lists the affected and patched versions. If you're searching for n8n CVEs, start there. It's n8n's own record of each issue and the versions that fix it.

When we checked on 12 October 2026, the advisory list ran to 21 pages. The first page alone had ten advisories published on 30 September 2026, and eight of them were rated High.

Any platform that runs code, holds credentials and accepts webhooks gets a steady flow of security fixes, and n8n is no different. So someone has to own patching, because a self-hosted instance that nobody updates stays exposed.

Here's the routine we'd suggest for a business running self-hosted n8n:

1. Name one person who checks the advisories page, and put it in their calendar every week.
2. For each new advisory, compare the version your instance runs against the affected range.
3. Check whether you use the node or feature it names. That tells you how urgent it is for you. Patch either way.
4. Read the release notes for breaking changes, test the update on a copy, then update production.
5. Re-run the security audit and the failure tests from this checklist once you're on the new version.

n8n's own advice is to update at least once a month, so you never have to jump several versions at once. Its release notes are also published as an RSS feed, which is an easy way to see new versions land. If you find a vulnerability yourself, n8n's security policy asks you to report it through its Vulnerability Disclosure Program.

Sources: n8n security advisories on GitHub, n8n update guidance, n8n release notes and the n8n security policy.

Worked example: reading one n8n advisory

Take one of the 30 September advisories, GHSA-728h-pmr2-7cgh: "Send-and-Wait HMAC Bypass Allows Unauthenticated Approval of Waiting Executions". It's rated High. In plain terms, n8n says someone holding an execution's resume token could release an approval meant for someone else. Everything after that step then runs under the workflow owner's credentials.

Now say your instance runs 2.41.2, and your team uses a Send-and-Wait step so a manager approves refunds before they go out. Here's how we'd work through it.

1. Are you affected? The advisory lists versions before 2.41.4, and 2.42 releases before 2.42.1. Version 2.41.2 is in that range.
2. What fixes it? 2.41.4, or 2.42.1 and later. So you can take the small patch on the line you're already on, and plan the bigger version jump separately.
3. How exposed are you? You use the exact feature, on an approval that moves money. For you, this one goes to the top of the list.
4. What do you test after patching? The approval path again (checks 8 and 9 above), then a fresh security audit.

None of that is hard, as long as someone owns the patching.

Upgrading to n8n v2 safely

n8n 2.0 is a major release. n8n describes its changes as improving security, simplifying configuration and removing legacy features. Several of them will stop an older workflow from running, so treat the upgrade as a production change and put it through this checklist like any other.

Start with the migration report. In n8n, go to Settings > Migration Report. It's available to global admins only. It tells you how many of your workflows are compatible with n8n 2.0, and splits the problems into workflow issues and instance issues. Each workflow issue lists the workflows and nodes affected, how many times they've run and when they last ran. In n8n 2.43, released on 6 October 2026, the report started grouping issues by their impact, with anything that blocks the upgrade listed first.

These are the v2 changes we'd expect to cause the most trouble in a business setup:

A safe n8n v2 upgrade, step by step

1. Back up the n8n database and the encryption key, and check you can actually restore them.
2. Run the migration report. Fix every blocking issue and anything that will make executions fail.
3. Switch on the new defaults early, on the version you run now, where n8n allows it: N8N_RUNNERS_ENABLED=true, N8N_SKIP_AUTH_ON_OAUTH_CALLBACK=false and N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true.
4. Upgrade a copy of the instance first and run your important workflows against test data.
5. Pin an exact version number. n8n has renamed its release channels from latest and next to stable and beta, so a moving tag can change under you.
6. Upgrade production, then re-run the test matrix from check 9, the security audit and a readback on your most important writes.
7. Watch the first real runs of every published workflow, especially sub-workflows and anything with an approval step.

One more thing to plan for. n8n has already published its breaking changes for 3.0, and self-hosted 3.0 needs a Docker-based deployment. Installs run with npm or npx aren't supported. If your instance runs that way, the v2 upgrade is a good moment to move it to Docker, so you only rebuild the hosting once.

Sources: n8n v2.0 breaking changes, n8n v2.0 migration tool and n8n v3.0 breaking changes.

What passing the n8n production checklist looks like

A workflow is ready when the team can show evidence for each check, not just say it is covered. That evidence might be a duplicate test that created one destination record, an expired-credential test that produced the right alert, a readback confirming every invoice line, or a second staff member following the runbook without help.

That standard may feel slower than switching a workflow on after a successful demo. It is much faster than untangling duplicate records, missed work or an automation nobody feels safe touching.

A few of these checks come standard on everything we hand over. Each build has error alerts: a failed run retries, and if it still fails, Ben gets an email, so problems get caught before you'd notice them. The handover includes a written guide, recorded walkthroughs, a runbook for what to check if something stops and a documented way to switch each automation off. The compliance system we built for an NDIS provider in n8n also had its own dedicated error-handler workflow.

Already have an n8n workflow running? We can review the setup, test the failure paths and quote the fixes as one fixed price in writing before any work starts. See our n8n development service or book a free 30-minute call.