The flow that ran and did nothing

A flow that errors gets fixed. A flow that runs and does nothing runs forever.

Everyone building automation eventually learns that failures are the easy case. The expensive case is the run that completes successfully while accomplishing nothing.

Four ways a healthy-looking run does nothing

The filter that matches zero rows

A step filters yesterday's orders by status. Upstream, someone renames the status from completed to complete. Your filter now matches nothing. The flow runs, the filter succeeds at filtering, the summary step summarises an empty list, and a message goes out saying zero orders. Every step returned success.

The API that changed its empty response

An endpoint used to return 404 when there was no data. A version bump changes it to return 200 with an empty array. Your error handling was watching for the 404. Now there is nothing to catch.

The credential that quietly lost a scope

A token gets rotated with narrower permissions. The call returns 200 with a partial payload rather than 403. You are now processing a subset and cannot tell.

The step that never ran

The most invisible of all, and the one I hit in our own deploy pipeline — a build step that was never configured, so it never ran, so it never logged, so nothing indicated its absence. That story is the build that succeeded at nothing.

Why run-level status cannot catch these

A run status is a single bit: did the sequence complete. Every failure above completes. If your monitoring asks "did the flow run?", the answer is yes in all four cases, and yes is what you were checking for.

The question you actually want answered is "did the flow do what it did last time?" — and that requires knowing what each step received and produced, not merely that it finished.

Practical defences

• Assert on shape, not just success. If a step normally returns between 10 and 500 rows, zero rows is an anomaly worth surfacing even though it is not an error.
• Alert on absence, not only on failure. "This flow has not produced output in 3 runs" catches things "this flow errored" never will.
• Keep per-step history. When you eventually notice something is wrong, the only way to find when it started is a record of what each step returned over time.
• Be careful with the alert path itself. If your failure notification goes through the same integration that failed, you have built a system that goes quiet precisely when it matters. Worth testing that alerts fire by deliberately breaking something.

The uncomfortable version

Most automation dashboards are optimised to show you green. That is what people want to see, and it is what gets built. But a green dashboard answers a question you did not ask. The useful dashboard is the one that can tell you a flow's output has changed shape — and that requires having kept the shape.