The 7 mistakes in almost every beginner n8n workflow
I have rebuilt a lot of workflows that mostly work. The same seven problems show up every single time.
Part of my freelance work is fixing workflows that mostly work. Different businesses, different tools, the same seven problems every time. Check your own builds against this list.
1. API keys typed into nodes
A key pasted into an HTTP Request header gets exported with the workflow, shared in screenshots, and committed to git. n8n has a credentials system that encrypts secrets and, this is the important part, leaves them out of exports. If your JSON export contains anything that starts with sk-, fix that today. And get a new key while you are at it.
2. Only testing the happy path
The workflow works when the API answers nicely. What happens when the search returns zero records? When the API times out? When a field is empty? Most workflows I inherit have never seen an empty result. Run your workflow once with broken input on purpose before you call it done.
3. Not safe to run twice
If the same trigger fires twice, and it will, does your customer get two invoices? Status fields (mark items before processing) or checking for an existing record first make repeat runs harmless. This is the single most valuable fix on this list.
4. Referring to data by position
Expressions like "take the value from three nodes ago" break the moment you insert a node in between. Refer to nodes by name instead, like {{ $('Search Todo').item.json.id }}. Renaming and moving things around stops being scary.
5. One giant workflow
Forty nodes, three triggers, everything tangled together. It works, until the day you need to change anything. Split by job: one workflow takes things in, one processes, one publishes. They talk to each other through the database (see mistake 3) or webhook calls. Small workflows are easy to test. Giant ones are digging work.
6. Ignoring the error side
n8n has error workflows: a separate workflow that runs whenever another one fails, with the failure details as input. Ten minutes of setup gets you a Telegram or email message the moment something breaks. Without it, you find out from a customer, days later.
7. Forgetting timezones
A Schedule trigger set to 8 PM means 8 PM in the workflow timezone setting, which defaults to whatever the server thinks. Docker containers usually think it is UTC. If your posts go out at odd hours, check Settings → Timezone before you touch the trigger.
None of these need more nodes or smarter logic. They are habits. And they are the difference between a demo and a system you can trust with your business.