n8n beginner mistakes that only show up in production

The editor is a kind liar. You pin sample data, click Execute, see green, and assume the live path is the same. Production is a different machine: real payloads, real rate limits, empty fields, and no one watching the canvas. The mistakes below are the ones that turn a helpful workflow into a quiet failure or a loud embarrassment.

None of this requires a platform team. It requires a short list of habits you apply before you flip a workflow to Active.

No error path, so failure looks like success

A node that errors will stop the run. If you never attached an Error Trigger workflow, the only record is an execution with a red X that you will not open because you were in a client meeting. Meanwhile the form user thinks they submitted, or the invoice reminder never left.

Add one global error workflow on day one: Error Trigger → email or chat to you with workflow name, execution id, and the error message. For important branches, use Continue On Fail on nodes that should not kill the whole run, then IF on the error output. Silence is the actual outage.

The test webhook is still in the form

n8n gives you a test URL and a production URL. The test URL only hits the editor while you are listening. People paste the test URL into Tally, Stripe, or Calendly, go live, and wonder why nothing runs unless the canvas is open. This is so common it should be a sticker on the monitor.

Before you activate, copy the production webhook URL into the source app and send a real event from that app, not from “Listen for test event.” Confirm an execution appears with the workflow Active and the editor closed. Then bookmark the production URL in the workflow notes.

Secrets sitting in Function nodes

API keys in a Function node get copied into executions, exports, and screenshots. Credentials exist so keys live encrypted and can be rotated. Use the Credential store even for “just a header.” If a third-party API has no credential type, use Header Auth or a custom credential, not a string in the node.

Same rule for customer data. Pinning production payloads to debug a problem is useful for ten minutes. Leaving pinned personal emails in a shared export is how you leak a list. Unpin when you are done. Do not export a workflow with production data still pinned.

Assuming the sample item looks like Tuesday

Pinned data is one happy item. Live data is missing optional fields, arrays of one, arrays of none, and encoding surprises in names. A node that does {{ $json.email.toLowerCase() }} will throw when email is blank. A loop that assumes attachments[0] will die on a text-only message.

After it works on pinned data, run it on three ugly real examples: empty optional field, two items, a unicode name. Add IF guards. Prefer optional chaining in Code nodes. If a field is required for the business, fail with a message you will understand next month, not a TypeError.

Timezones, retries, and double sends

Schedule nodes without an explicit timezone will use whatever the instance uses, which may be UTC on a VPS. You then “fix” a missed run by adding a second schedule. Two schedules plus a retry on the email node is how a client gets paid-reminder × 3.

Set TZ and GENERIC_TIMEZONE. Put a unique key on sends (invoice id + step + date) and check it before you email. Enable retries only on nodes that are idempotent: fetching a list is; sending mail is not, unless your provider dedupes. When in doubt, retry the fetch, never the send.

Binary files as a second database

Downloading every attachment into the workflow “so we have it” fills the disk and slows executions. Process the file, store it in Drive or S3, keep the URL, drop the binary. Set a payload size limit. If you must keep files, keep them off the n8n volume.

The same idea applies to HTTP nodes that pull an entire CRM dump to find one contact. Filter at the API. Paginate on purpose. A workflow that works at ten records will time out at ten thousand without telling you a useful story.

Active without a backup

Export the workflow JSON the day it goes live. Put it somewhere that is not the same VPS. If you self-host, back up the data volume and the encryption key. If you use n8n Cloud, still keep JSON exports of the workflows that move money or email clients.

Write a three-line runbook in the workflow sticky: what it does, what “healthy” looks like (an execution in the last N hours), and who gets the error mail. That is enough. You do not need a wiki. You need to remember it exists when you are tired.

A go-live bar

Do not activate until you have: production webhook in the source app, an error notification that you have actually received in a test, a send that cannot double-fire, no secrets in Code nodes, and an export saved off-box. That list is shorter than a rewrite. It is the difference between a playbook and a hobby canvas.