Why Your Automation Worked Twice and Then Broke
- Tomasz Dylik
- Jul 31
- 5 min read
It worked on Monday. It worked on Tuesday. On Wednesday it did nothing at all, and it did not tell you.
If you have spent an evening staring at a canvas where every box is grey and nothing explains why, you are not the only one. This is the single most common message I get about automation, and it almost always comes with the same word attached: randomly.
It was not random. That is the good news, and it is also the whole point of this post.
Your automation did not break.
Nothing inside it changed. The steps are the same steps, in the same order, with the same settings. Nobody touched it.
What changed is what arrived.
An automation is not a machine that wears out. It is an agreement about the shape of the incoming data. You wrote that agreement without noticing, based on the two or three examples you had in front of you while you were building. Every field was filled in. Every value was the type you expected. There was exactly one item in the list.
Then the world sent something else.
Once you see it that way, the mystery goes. You are not looking for a fault. You are looking for the first message whose shape you never agreed to.
The five things it usually is, in order.
I have put these in the order I check them, which is roughly the order of how often they turn out to be the cause. Work down, not around.
01 · A connection expired. Tokens time out, passwords change, somebody revoked access to a shared account, a trial ended. This is the most common cause on every platform and it is the least interesting, which is why people check it last. Check it first. The tell is that the whole thing stops rather than misbehaving.
02 · A field arrived empty, and empty is not the same as missing. This one is worth reading twice, because it is the cause people never find. A field that exists and contains nothing, and a field that is not there at all, are two different conditions. Your check passed when it should have failed, or the other way round, and everything downstream carried on politely with nothing in its hands.
03 · The data changed shape. A connected tool renamed a field in an update. A value that was always a number came through as text. One item became three items. Nothing failed, exactly. It just stopped matching what the next step was reaching for.
04 · You hit a limit. An operations quota, a rate limit at the other end, or a conversation that grew long enough to push your earlier instructions out of the model's working memory. The industry calls that last one the context window. The tell for all three is timing: it works in the morning and dies in the afternoon, or it works for the first forty records and not the rest.
05 · The loop never closed. If you are processing a list in batches and the loop is not wired back correctly, the first batch runs, the workflow reports success, and the other nine batches simply never happen. Nothing is red. Nothing is wrong. Nine tenths of the job did not occur.
There is a sixth that deserves its own warning, because it does not fail at all. If you split a workflow into two paths and bring them back together with the wrong merge setting, you get output that looks completely fine and is wrong underneath. Appending stacks records on top of each other. Combining matches them by a key. Choose the wrong one and you will find out weeks later, in a spreadsheet, in front of somebody.
The free AI Agents pack. The checklists I actually use are in there, including the one for reliability and the one for deciding what may run without a human. Plus over two thousand ready-made n8n workflows, a workbook on the twenty building blocks that cover most of them, and the Agent-Plus Prompt Builder for writing agent instructions. Download the AI Agents pack →
The same failure, with and without a way to hear about it.
Without. It fails on Wednesday. You find out on Friday, because somebody asks why they never got the confirmation. You now have two problems: the fault, and two days of records that were never processed and that nobody wrote down.
With. It fails on Wednesday. Ninety seconds later you get a message saying which workflow, which step, and what the error said. You fix it before lunch and re-run the three records that missed.
The failure is identical. The difference is entirely in what you built around it.
Both platforms give you this and almost nobody sets it up, because it takes twenty minutes and adds nothing on the day you build. It is the clearest line I know between an automation that is a hobby and one you can put weight on.
Three things to add once, to every workflow you care about.
Copy this list. It is short on purpose.
An error route that tells a human. Not a log you will never open. A message, to the place you already look.
A note on the canvas saying what this assumes. One sentence. This assumes every contact has an email address and that the list arrives sorted. Sticky notes are the most-used element in n8n and they do nothing at all, which is exactly why they matter. In six months the person who has forgotten why you built it this way is you.
A deliberate path for the empty case. Decide now what should happen when the field is blank. Skip it, flag it, or stop. Any of the three is fine. Having no answer is what produces the silent Wednesday.
What this will not do.
An error route does not stop things failing. It stops them failing quietly, which is a different and much more valuable thing.
Retries do not repair bad data. If the record was wrong the first time, it will be wrong the fourth time, and you will have paid for four attempts.
And none of this removes maintenance. Anything connected to other people's software is something you look at now and then, because they will keep changing their end without asking you. That is not a flaw in your build. It is what owning a small machine is like, which is also the honest answer to whether you needed an automated system here in the first place.
One small thing to do before the next post.
Open the workflow you would most hate to lose.
Write one sentence describing what it assumes about the data coming in. Not what it does. What it assumes.
Then put that sentence on the canvas as a note.
It takes four minutes, and the sentence is usually the bug. Most people find the answer while writing it, before they have tested anything.
If you want the whole thing in one place.
If you would rather have the complete system than one piece at a time, that is what I wrote AI Agents Bible for. Five books in one, with Custom GPTs, Make.com and n8n each built step by step, thirty worked examples you can copy, and the parts most guides leave out, about cost, reliability and knowing what not to let run on its own.
Both this and the prompt engineering book also come as one 12-in-1 volume, if you would rather have the whole system in a single place.



Comments