Your automation stopped running and nobody told you
The hard part is almost never fixing it. The hard part is that it kept reporting success. Below are six ways a run does nothing and says it worked, each one a failure we hit in production and had to diagnose, with the tell that separates it from the others.
None of this is specific to us. If you are on Zapier, n8n, Make, or something you built with an AI tool, these are the same six.
Six ways a run lies about itself
Most engines let a failing step choose what happens next, and the common default is to skip it and carry on. The error lands on the step, the run finishes, and anything downstream that referenced it quietly becomes empty.
How to tell. Read the STEP results, not the run status. A step marked skipped that also carries an error is a failure wearing the wrong word.
A dispatcher can complete, mark the run a success and advance the next run time without the job at the other end ever being called. Every screen you can check then agrees it worked, and there is no run anywhere to explain the silence.
How to tell. Look at the duration. A real run takes tens of seconds. An execution that completed in milliseconds did not do anything.
A filter that names a field the incoming rows do not have matches nothing, and an absent field usually scores as a clean false rather than as undecided. Nothing raises an error. The next step then works from whatever it does have, and produces a confident, plausible, entirely wrong answer.
How to tell. Count what went in against what came out. In went 900, kept 0, and nobody objected is the shape to look for.
Most hosting has a hard response-size limit. Past it, the function returns normally and the platform in front of it replaces the answer with a generic error. Neither side logs a failure. The same job works on a small result and fails on a large one, which makes it look intermittent.
How to tell. It is size-dependent. If it works at forty rows and fails at six hundred, it is a limit, not a bug in your logic.
When a setting is threaded through several layers, one hop can drop it. Every layer above is correct, the change looks applied, and the only observable difference is that more came back than you asked for. A narrowed read and a wide one both return rows.
How to tell. Nothing will tell you. Assert on what actually left the last hop, not on what you passed into the first.
Checks often live on the path that is still holding the response. A job that outlives that window finishes somewhere else, reports a bare status, and skips the layer entirely. The check is correct and simply unreachable, for exactly the long jobs nobody sits watching.
How to tell. Ask whether your checks run on the slow path as well as the fast one. If they only ever ran on quick jobs, they have never seen a real one.
What to check first
The pattern underneath all six
A run status answers a narrow question: did the code reach the end. It cannot answer the one you care about, which is whether the work happened. Those two come apart constantly, and every failure above is an instance of them coming apart quietly.
Which is why the useful record is not a log of steps but an account of what was read, what changed, and what looked different from last time. A step log cannot contradict itself. Something assembled from what came back can.
We build automations that report themselves this way, because we got tired of the six above. To be straight about the limits: it tells you when something stopped and what a run actually did. It does not repair it for you.
See how it reports a runOr browse the prebuilt automations.