How can an automation report success and still do nothing?

31 July 2026 · Daniel Thomas · 9 min read

This matters more than it sounds. A broken automation that fails is a nuisance for an afternoon. A broken automation that reports success can run for weeks, and the first person to find out is usually a customer.

Shape one: the template that was never evaluated

In n8n specifically, a parameter is only an expression when its value begins with =. So these two look identical in a screenshot and behave completely differently:

Zapier, Make and Power Automate each have their own version of the same trap, usually a field that has to be switched from "text" to "expression" or "formula" mode before the braces mean anything.

How to test it in two minutes

1. Find the outgoing request in your tool's execution log and look at the headers it actually sent, not the ones you configured.
2. If you see braces in the sent value, the field was never evaluated.
3. If you cannot see sent headers at all, call the same endpoint yourself with the literal text and check the error you get back. Most APIs answer with something unambiguous like invalid_api_key.

Shape two: the update that matched zero rows

This shape is common in unsubscribe links, order status updates and "mark as paid" steps, because all three key off an identifier that arrives from outside. A typical broken unsubscribe looks like this:

• The email link is missing its identifier, or carries an empty one.
• The workflow defends itself by substituting a fallback value, often 0.
• The update runs WHERE id = 0, matches nothing, and succeeds.
• The next step writes a log line saying the person was unsubscribed.
• The person keeps receiving email, and the log insists they were removed.

An unsubscribe that silently fails is not merely a bug. Under UK GDPR and PECR, honouring an opt-out is a legal obligation, and "our system said it worked" is not a defence.

How to test it in five minutes

1. Count the rows the operation claims to have changed. Every database driver returns this, and most automation tools expose it as affected rows or by returning the changed row itself.
2. Make zero rows an error, not a success. If nothing changed, the run should go red and say so.
3. Then check the outcome table directly. For an unsubscribe, count how many records are actually marked unsubscribed and compare that with how many times the endpoint reported success. Those two numbers should match. When they do not, you have found this exact shape.
4. Stop keying destructive or legally significant actions off a bare integer. A signed token, or a match on the email address itself, fails loudly when the link is mangled instead of quietly matching nothing.

Shape three: the schedule that stopped firing

Two things commonly cause it, and neither announces itself. The first is a platform restart or migration that does not re-register the schedule, so the job is still marked active but is not in the scheduler. The second is retention settings: many tools save only failed runs by default, so a successful run leaves no trace at all, and "no records" becomes ambiguous.

That ambiguity is the real problem. If successful runs are not stored, then "zero executions" is equally consistent with ran perfectly every day and with never fired once, and no amount of staring at the execution list will tell you which.

How to test it properly

1. Stop asking the execution log whether the job ran, and ask the side effect instead. If the job writes rows, chart those rows by day. A gap in the data is proof of a gap in the runs, and it is proof you can show someone.
2. Give every scheduled job a heartbeat: one unconditional row, or one daily "still alive" message, written whether or not it found work. A monitor that only speaks on failure is indistinguishable from a dead one.
3. Check your retention setting before you interpret an empty list. Knowing that successes are discarded changes what the emptiness means.

What ties all three together

A short list worth running against any automation you depend on:

• What row, message or file proves this ran today? If the answer is "the green tick", you cannot prove it ran.
• What does this step do when it matches nothing, receives nothing, or gets rejected? If the answer is "carries on", that is the bug.
• If this stopped completely tonight, what would tell me, and when?

None of this requires better tools. It requires one habit: before believing a dashboard, go and look at the thing the automation was supposed to change.