Why “It Didn't Error” Doesn't Mean It Worked

There's a quiet assumption baked into most monitoring setups: if nothing threw an error, the thing worked.

That assumption is wrong often enough to matter, and it's wrong in a specific, predictable way. A workflow doesn't need to crash to fail. It just needs to finish successfully while doing nothing.

The three gates a workflow actually passes through

Break down what “it worked” really means, and there are three separate questions, not one. Most monitoring stops at the first two.

Gate three is the only one that tells you the thing you actually cared about happened. And it's the one almost nothing checks by default, because it requires knowing what “correct output” looks like for that specific workflow, which is harder to define than “did it throw an exception.”

What gate three failures actually look like

These aren't exotic edge cases. They're some of the most common ways automations quietly stop working:

A token expires. The workflow still runs. The API call still returns a response. It's just a 401 wrapped in a response body that some workflows don't inspect closely enough to notice, so the workflow logs “done” and moves on.

An API changes its response shape. The field your workflow reads is still there, just nested one level deeper than before. The workflow doesn't error, it just reads an empty value where it used to read real data, and passes that empty value downstream as if it were correct.

A source starts returning an empty array instead of actual records. Zero is a valid response, technically. The workflow finishes. The dashboard looks the same as any other successful run. Nothing about the execution log distinguishes “correctly processed nothing” from “correctly processed everything.”

✓ workflow executed
✓ every node reported success
✗ zero records actually landed downstream

Why this isn't a case for more error handling

The instinct is to add more try/catch blocks, more retries, more validation inside the workflow itself. That helps with a different problem. It doesn't help here, because the workflow genuinely isn't erroring. It's succeeding at doing nothing, and no amount of error handling catches a success.

What catches it is a check that lives outside the assumption that “ran without error” means “worked.” Something that compares what was expected against what actually arrived, independent of whether the workflow itself reported a problem.