Stop
Ends the run with a declared status and message.
Purpose
Terminates the run immediately and declares how it ended: success, failure, or cancelled, with an optional message.
When the flow is used as a Sub Flow, the Stop's status becomes the flow's return value — the parent branches on it.
When to use it
- Marking a successful completion.
- Ending a run deliberately when a precondition is not met.
- Giving a Sub Flow its return value.
- Terminating any wired path that should not continue.
When not to use it
- To leave a loop — use Break.
- To skip one loop pass — use Continue.
- To end the flow from deep inside a loop where a Stop would be awkward — Return does the same job and reads better.
Requirements
A final status. The message is optional but strongly recommended.
How it runs
When the runtime reaches a Stop node it finalizes the run with the declared status and message. No edge is resolved — Stop is terminal, and it has no output ports.
Stop counts as an executed node against maxNodeExecutions.
Settings
| Setting | Type | Range | Notes |
|---|---|---|---|
| Final status | choice | success, failure, cancelled | Required |
| Message | string | ≤ 500 chars | Optional. Appears in the run log |
Choosing the status
| Status | Means |
|---|---|
success | The flow did what it set out to do — including "there was nothing to do" |
failure | The flow could not complete its job |
cancelled | Ended deliberately without being either a success or a failure |
A flow that checks for a daily reward and finds none already claimed it. That is a success, not a failure — the desired end state holds.
Reserve failure for "I could not do my job", because that is what your alerts and your parent flows will branch on.
The message is your log
Set a message on every Stop, especially failing ones. That string is what you read when a run fails overnight.
"All slots full" tells you what happened. A node id tells you nothing.
Ports
Stop is a terminal node. It has no output ports — nothing is wired out of it.
Basic example
- Final status: success
- Message:
"Daily rewards collected"
Realistic example — distinct endings
Give a flow one ending per meaningful outcome:
All three are successes — the flow behaved correctly in each case — but the messages tell you which happened without opening the graph.
Advanced example — Stop as a Sub Flow's return value
When a flow is called by another, its Stops are its interface:
Two Stops with clear statuses give the parent exactly two branches to handle. This is what makes Sub Flows behave like functions.
Best practices
- Write a message on every Stop. Non-negotiable for failing ones.
- Use
successfor "nothing to do". - Give a Sub Flow exactly the endings its caller needs — usually one success and one failure.
- Wire every dead-end path to a Stop. An unwired route finalizes with
TRANSITION_NOT_FOUND, which tells you far less than your own message. - Make messages actionable — say what state the flow was in, not just that it failed.
- Do not fear multiple Stops. Several well-labelled endings beat one shared ending with a variable explaining it.
Performance notes
- Stop costs nothing; it finalizes the run.
- It consumes one execution against
maxNodeExecutions. - Reaching a Stop early is the cheapest possible outcome — a well-placed guard that stops immediately saves the entire remaining flow.
Memory notes
- Finalizing releases the run's execution context, including
run-scoped Runtime Memory. persist,sessionandsharedmemory survive; that is their purpose.
Common mistakes
| Mistake | What happens | Fix |
|---|---|---|
| No message on a failing Stop | Unreadable logs | Write the reason |
failure for "nothing to do" | False alarms; parents take recovery paths needlessly | Use success |
| Trying to wire out of a Stop | It is terminal | Use Return or restructure |
| Using Stop to leave a loop | Ends the whole run | Use Break |
| Unwired failure routes | Run ends TRANSITION_NOT_FOUND | Wire them to a Stop |
| One Stop for every outcome | You cannot tell what happened | One per meaningful ending |
Troubleshooting
The run ends with TRANSITION_NOT_FOUND instead of my Stop.
Some route had no edge wired. Find the last node in the log and check its ports.
A parent flow takes the wrong branch after calling a child. The child's Stop declared the wrong status. Check which Stop it actually reached.
The run log shows no reason. No message was set on the Stop that was reached.
A cancelled Stop looks like a user cancellation.
It is a declared status, not an actual cancellation. Use it sparingly — success or failure is usually clearer.
FAQ
Can a flow have several Stop nodes? Yes, and it usually should.
Does Stop count toward maxNodeExecutions?
Yes. So does Start.
What is the difference between Stop and Return? Both finalize the run with a declared status. Return is designed to be reachable from anywhere, including inside a loop.
Where does the message appear? In the run log and the run's final result.
Related nodes
- Start — the entry point
- Return — finalize from anywhere
- Break — leave a loop instead
- Sub Flow — consumes a child's Stop status