Every course teaches you how to build something. Almost none of them teach you what to do when it stops working, which is strange, because that's the part you'll actually spend more time on once you have a few automations running.
The real challenge is that automations don't break loudly. The workflow just quietly stops doing its job, and everything looks fine until it obviously isn't. The damage doesn't live in the failure. It lives in the gap between when it broke and when you noticed.
Say your lead notifier stops firing on a Friday afternoon for example. Nothing seems or looks wrong, and you don't get an error. But at the same time you're not getting anything at all. Then Tuesday a client asks why nobody followed up on the four people who filled out a form over the weekend. Those leads sat there for three days. The automation doesn't cost you anything when it works. It costs you when it fails and stays quiet.
When something's off, don't just start poking at nodes at random. Work through it in order. These four categories are roughly the sequence in which things usually fail, and each one is fast to rule out before you move to the next.
That order also tracks how quickly each type of failure gets loud. Trigger and auth problems tend to surface fast once you know where to look, since the workflow either doesn't run at all or throws an error you can read. Data and downstream failures take longer to notice, because the workflow runs and looks fine. That's exactly why they belong later in the list and why they do more damage by the time you catch them.
The trigger didn't fire
How to recognize it
Nothing happened at all. This is the key distinction. Open your executions list and check to see if there's no run when there should have been one. Not a failed run that's highlighted red. No run, period. An empty log means the workflow was never initiated. If you see a red failed execution instead, skip this category, because the trigger clearly fired and something went wrong down the line.
Fastest way to check
Look at the executions list and check whether the workflow is even active. The most common reason nothing happened is that the workflow got switched off, usually after an edit, and was never switched back on. For a scheduled workflow, check the time zone it's set to run in, because n8n runs on the zone it's configured with, not the one you live in. For a webhook, send a manual test to the URL and watch for a run to execute.
How to fix it
Flip the workflow active. If it's a webhook, confirm the outside tool is still pointed at the right URL. n8n gives you a test URL and a production URL, and they are not the same. Leaving the test URL in your form settings is a classic one: it works while you're in testing and fails if you leave it that way.
The habit that prevents it
After any edit, confirm the workflow is active before you close the tab. And build a heartbeat, a tiny scheduled message that tells you the thing is alive, so silence itself becomes something you'll notice right away.
Auth or credentials failed
How to recognize it
The run happened and failed, and the error talks about authorization, a token, something expired, a 401, or "unauthorized." The giveaway is the feeling that comes with it: it worked yesterday and you know you didn't touch it. That's a strong sign of an auth failure, because the thing that changed wasn't anything that you did specifically. A token expired, a password got rotated, or someone revoked an app's access.
Fastest way to check
Open the failed execution, find the node with the red mark, and read the error. Auth problems say so in plain words. Then open that credential inside n8n and re-test it. If reconnecting makes the test pass, you've found it.
How to fix it
Re-authenticate the connection. For OAuth logins like Google, that means reconnecting your Google credentials. For an API key, generate a fresh one and paste it in. If the cause is on someone else's end, like a client who changed a password or pulled your access, nothing in n8n fixes it until they restore it.
The habit that prevents it
Know which of your connections rely on tokens that expire, and reconnect them on your own schedule before they lapse instead of after. Where a tool offers a long-lived key or a service account instead of a personal login, use it. Then one person changing their password doesn't quietly take the whole thing down.
The data format changed
How to recognize it
The run failed somewhere in the middle, and the error is about a missing field, an undefined value, a type that didn't match, or a node that got an empty input it wasn't expecting. The trigger fired and auth was fine, but partway through, a node reached for data that wasn't shaped the way it's supposed to be. This one often follows a change nobody flagged to you: a form field got renamed, a new required question was added, an upstream tool tweaked its output.
Fastest way to check
Open the failed run and click through the nodes left to right. n8n shows you the real data moving between them. Find the first node where the input looks wrong or blank. Your break lives between the last good node and the first bad one, and it's usually a field name that changed or a value that came through empty.
How to fix it
Update the mapping to match the new names or structure. If a field can legitimately be empty sometimes, add a check so a blank doesn't take down the entire run.
The habit that prevents it
Don't build as if your data will stay identical forever, because it won't. Add a validation step early in the workflow that confirms the important fields exist before the rest of it runs, and have that step tell you when something's missing instead of failing three nodes later with a cryptic error. And when you change a form, remember: the workflow reading that form does not update itself.
The action failed downstream
How to recognize it
This is the quiet one, and the most dangerous. n8n shows you a green, successful run. No error anywhere. But the outcome you were looking for either didn't happen or came out wrong. The message went to the wrong channel. The row landed in the sheet with half its columns blank. The email sent, but to the test address you forgot to swap out. Clean run, wrong result. That combination is the whole signature, and it's the failure most likely to run unnoticed for weeks, because every signal you're watching says everything is fine.
This is the one that costs the most precisely because nothing tells you to look. A weekly report emailing itself to a test inbox instead of the client can run green every single time for a month straight, and you won't know until someone asks why they never got a single one.
Fastest way to check
Don't trust the checkmark. Go look at the destination. Open the Slack channel, the Google sheet, the inbox, and see what really arrived. Then open the successful execution and read the output of the final node. n8n shows you exactly what it sent, which usually makes the wrong value or the wrong target obvious.
How to fix it
It's almost always a config detail in that last node. A wrong channel ID, the wrong sheet or tab, a mapping that dropped data into the wrong column, a stale test recipient. Fix the target or the mapping, run it once, and confirm at the destination rather than in n8n.
The habit that prevents it
Verify at the destination, always. A run reporting success only means the workflow finished, not that it did the right thing. When you build something, do one real end-to-end test and go look at where the output is supposed to land with your own eyes, not at the green checkmark. For the workflows that matter, build the check into the workflow itself, so it confirms the thing arrived or sends you the result where you'd catch it if it were wrong. Trusting the checkmark is exactly how a broken automation runs happily for a month while you sit there certain it's working.
None of these four things are hard to check once you know to look for them. The skill isn't technical. It's knowing where to look first, and trusting what you see there instead of assuming the thing is fine because it usually is.