Read what happened in a run

A finished run hands you one word: Succeeded, Failed, Stopped, Expired. Where to find that word, and what each one means, is covered in Run a flow and watch it.

This page is about the harder question underneath. That word is not a verdict on whether the work got done — it is a report on how the flow ended. The two come apart more often than people expect, and knowing how is what turns a failed run into a fix.

Succeeded can mean "quietly stopped early"

Learn this trap first, because nothing warns you about it.

A run walks from node to node along the edges. When it reaches an output with no edge attached it stops — and the editor is explicit about what that counts as:

"out, true, false, case, timeout unconnected: the flow ends successfully there."

So a flow of twenty nodes that was only wired up for the first six does not complain. It runs those six, finds nothing after them, and reports Succeeded. The same goes for a branch you forgot: an If with its false output left dangling ends the run every time the condition is false, and calls that a success.

Succeeded means the flow ran out of edges without erroring. It does not mean the app did what you wanted, and it does not even mean the flow reached the end you had in mind.

Before trusting a green run, look at the canvas and ask which outputs have nothing attached. Every one of them is an exit.

Inside a loop the same rule reads differently: "Inside a loop body an unconnected output ends the iteration." There, a loose output is normal — it is how a round finishes. Which is exactly why the habit is easy to pick up and carry somewhere it does harm.

Failed is not always a crash

Three quite different things all arrive as Failed.

Your flow said so. The Stop flow node carries a result code, and the editor describes the choice like this: "Success: the flow ends well. Failed: the flow stops and counts as a failed run; the runner sees an error." A flow that checks something and deliberately ends as Failed is working correctly. Read the flow before you debug it.

A step failed and had nowhere to go. Nodes that can fail have an error output — "The action failed: click found no element, HTTP error…". Leave it unconnected and "error unconnected: the flow stops and reports the failure." That is a real failure, and it is the common one.

Note the asymmetry, because it catches people: every other unconnected output ends the run as a success, but a dangling error ends it as a failure — even inside a loop, where "error still stops the whole flow."

It ran too long. A run still going after 30 minutes is cut off and marked Failed, reason TIMEOUT. The usual cause is a loop with no way out — a While whose condition never turns false, or a wait for a screen that never arrives. Give every loop a ceiling or an escape; see Node reference and Steering the flow.

Expired is not in this family at all. It means the phone never picked the run up within 5 minutes — a statement about the device, not about your flow, which was never tried. When a flow does not run works through that one by symptom.

Why one bad step can eat several minutes

A run that looks stuck is often just being patient on your behalf, and the arithmetic is printed in the editor:

"Number of RETRIES, not counting the first run (total runs = value + 1). Worst case = node timeout × (retries + 1) + rest × retries — a 15 s timeout with 5 retries is over a minute."

The order matters when you read things back afterwards: "Fail → rest this long → try again. Only after the last try does the node take the Error branch, and then the node’s own rest is skipped." The error you eventually see arrives long after the first thing went wrong. A handful of generous retry settings is how a flow that feels fine drifts towards the 30-minute cut-off.

Make the next run explain itself

The outcome tells you what. To find out where, you have to have asked in advance. Three tools, all cheap:

Plant Log nodes. The Log node exists for exactly this: "Writes one line to the run log — plant it to see how far the flow got and what the variables were". Put one after each stage that matters. Two log lines turn "it failed somewhere" into "it failed between these two points".

Put variables inside the message. The field's hint spells out the trick: "Written to the run log — embed {{variables}} to see their values at that moment." A value that looks right in the run dialog and wrong on the device is invisible any other way.

Take a screenshot at the turning points. The Screenshot node is described as "proof of how far the flow got", saved under a name you choose. A picture of the screen your flow was actually looking at settles most arguments in one glance — but mind that name: "Same name overwrites; embed {{variables}} to tell rounds apart." A fixed name inside a loop leaves you holding evidence from the last round only.

Name your nodes. Every node has a Display name, and "Leave empty to use the node type name" — which is how a twelve-step flow ends up reading Click · Click · Click. The placeholder suggests the style: "e.g. Tap Log in". Five seconds each, and the flow is still readable when you come back to it cold.

Reading a failure end to end

Put together, a failed run is usually read in this order:

The outcome and its reason — is this a genuine error, a TIMEOUT, or your own Stop flow doing its job?
Your log lines — the last one written tells you which stage it got through.
The screen it was on — your own screenshots, plus the screen structure captured with the failure.
The node itself — a step that could not find its element was either looking for the wrong thing or looking too early. Make your taps survive tomorrow covers the first, and waiting for the screen instead of guessing a delay covers the second.

Symptom-by-symptom causes — empty variables, a run displaced by another, a flow that worked yesterday — live in When a flow does not run.

Summary

Succeeded means the flow ran out of edges without erroring — an unconnected out, true, false, case or timeout ends the run there and still counts as success.
A dangling error output is the exception: it stops the run as a failure, even inside a loop.
Failed may be a real error, a TIMEOUT after 30 minutes, or your own Stop flow node reporting a result.
Retries multiply: a node's timeout times the number of tries, plus the rest between them.
Plant Log nodes with variables in the message, take Screenshots at the turning points, and give every node a Display name — before the run you will need to read.