DEV Community

Cover image for Junior Me Built Workflows That Work. Senior Me Builds Workflows That Survive.
Mychel Garzon
Mychel Garzon

Posted on

Junior Me Built Workflows That Work. Senior Me Builds Workflows That Survive.

I built an n8n workflow in 20 minutes. Then spent 3 hours figuring out why it stopped working a week later. Now I build differently. Here's what changed.


The problem with "it works" thinking

When a workflow runs successfully in testing, it's tempting to move on. But in a real company, automations run hundreds of times a day without anyone watching. The question is not whether it works today. It's whether it still works next Tuesday at 3am when nobody is around.


1. Use the Error Trigger node. Seriously.

n8n has a built-in Error Trigger node. Most people never touch it.

Connect it to Slack or email on every critical workflow. When something fails it fires automatically. But don't just send "workflow failed." Send context: which workflow, which node, what the input was, what the error said.

A useful alert fixes the problem in 5 minutes. A vague one wastes your entire morning.


2. Validate before you process

Add an IF node early in your flow to check that required fields exist and look right. If something is off, stop immediately and send an alert.

Catching bad data at the start is always cheaper than cleaning up after it.


3. Build for recovery

If your workflow processes records, check if they've already been handled before acting on them. A simple Google Sheet works fine as a state tracker.

This prevents duplicate emails, double charges, and very awkward client conversations.


4. Name things like a human

"Check if user exists" is a node name. "IF1" is not.

Use sticky notes to explain why you made certain decisions. A workflow a new person can read in 10 minutes is a workflow that will survive long term.


The shift

I used to ship a workflow and move on. Now I spend an extra 30 minutes asking "what breaks this?" before I close the tab. That's the whole difference.

That one shift changed how reliable my automations are. It also changed how much my clients trust them.

Reliability is not something you add at the end. It's the way you build from the start.


What's the worst silent failure you've had in automation? Drop it in the comments.

Top comments (0)