Stop Workflow Guide

Overview

The Stop Workflow feature lets you cancel a running workflow execution before it finishes. Unlike letting a workflow run to its natural completion, stopping it immediately signals the execution engine to halt — pending nodes never start, currently running nodes are aborted, and the workflow is recorded as terminated. This is useful for long-running scans you no longer need, accidentally triggered runs, or workflows stuck in a tight polling loop.

When you stop a workflow, the platform cancels every in-flight task it controls — currently running engine nodes and tasks already dispatched to the platform's workers (container scans, AI calls, integration calls). The one exception is work running on an External Agent: once an External Agent has picked up a task and started running the tool on your own infrastructure, the platform cannot reach in to cancel it. The workflow record is still terminated immediately, and any result the external agent eventually returns is discarded.

Use Cases

• Cancelling a runaway scan: terminate a workflow that's producing more data than expected, or scanning a wider scope than intended
• Aborting an accidental run: stop a workflow that was triggered by mistake (wrong inputs, wrong target, wrong schedule)
• Reclaiming long-polling loops: cancel a while loop that has been polling an external system longer than makes sense
• Maintenance windows: stop in-flight workflows before deployments, infrastructure changes, or scheduled downtime
• Incident response: terminate any workflow that is no longer relevant after operational priorities change

Stopping a Workflow

1. Open the running workflow execution
2. Click the Workflow actions dropdown
3. Select Kill workflow
4. Confirm the action in the prompt that appears
5. The execution will report that the stop has been requested and transition shortly afterwards

Note — stop takes effect asynchronously. After you confirm Kill workflow, the system publishes a stop signal that the workflow engine consumes within a few seconds. There is a brief window during which one or two more nodes may transition before the engine actually halts.

How Stopping Works

When you stop a workflow, the system goes through the following steps:

1. Authorization check: the platform verifies that you can see the execution (the same access rule that lets you read or download its results)
2. Stop signal published: a control event is broadcast to every running engine instance. Only the instance that owns the in-flight execution acts on it; the others ignore it
3. Execution loop exits: the owning engine stops dispatching new nodes
4. In-flight work cancelled: the platform's workers receive the stop signal and abort any container scan, AI call, or integration call they are currently running for this workflow
5. Running nodes marked terminated: any node currently in Running state is moved to Failed with the message "workflow stopped by user"
6. Workflow record finalised: the workflow execution's status is set to Failed and the same "workflow stopped by user" message is stored in its error field
7. External Agent results discarded: any task already running on an External Agent continues to execute on your own infrastructure. When (or if) it returns a result, the platform detects that the workflow has been terminated and silently discards the result

Resulting Workflow State

After a stop completes, you will see a mix of node statuses depending on where each node was in its lifecycle:

Node state at the moment of stop	Final state after stop
Finished successfully	Complete — preserved
Already failed before the stop	Failed — preserved with its original error
In progress on the engine	Failed — with the message "workflow stopped by user"
Running on a platform worker (container scan, AI call, integration call)	Failed — the worker receives the stop signal and aborts the task
Running on an External Agent	Failed — the workflow record is terminated immediately; the external agent runs the task to completion on your infrastructure and any result it returns is discarded
Not yet started	Remains Pending — these nodes never transitioned to running
Held (waiting on a trigger)	Remains Held

The workflow execution itself ends in Failed state with the error message "workflow stopped by user". This is the signal that distinguishes a user-initiated stop from a genuine failure.

Note — there is no separate "Stopped" status. A stopped workflow appears in the executions list as Failed. To tell a user-initiated stop apart from a real failure, look at the error message: stopped workflows always carry "workflow stopped by user".

Best Practices

• Use stop instead of waiting on stuck loops: a while loop with a long Max Iterations setting will continue polling until its cap; stopping the workflow is the fastest way to free the resources
• Be aware of the External Agent exception: tasks already running on an External Agent execute on your own infrastructure and cannot be cancelled by the platform. The workflow record is terminated immediately, but the external task itself runs to completion (its result, if returned, is discarded). All other in-flight work — engine nodes, container scans, AI calls, integration calls — is actively cancelled
• Plan re-runs as fresh executions: stopped workflows cannot be resumed. To continue or retry the work, start a new workflow execution

Common Error Patterns

Stop confirmed but no visible change: the stop signal is delivered asynchronously. Allow up to a minute for the engine to process it and update the execution record. If the workflow is still running after that, the engine instance that owns the execution may have an issue — contact support.

workflow stopped by user on a node that should have succeeded: this is the canonical stop marker. It does not indicate a problem with the node itself; it means the node was alive when the workflow was stopped.

External Agent task appears to still be running after stop: External Agent tasks execute on your own infrastructure, so the platform cannot interrupt them once they have started. The workflow record is terminated immediately; the external task may finish in the background and its result is discarded. All other in-flight work — engine, worker, integrations — is actively cancelled.

Limitations and Known Behaviour

• Stopped workflows cannot be resumed. There is no resume-after-stop path — the execution is terminal once stopped. Re-running the workflow starts a new execution
• No stop reason field. Killing a workflow does not accept a free-text reason. All stops are recorded with the fixed message "workflow stopped by user"
• No "stopped by" attribution on the execution record. The execution record does not currently display which user initiated the stop. The audit log holds this information if you need it for compliance review
• External Agent tasks already running cannot be cancelled. External Agent nodes run their tools on your own infrastructure. Once an External Agent has picked up a task, the platform cannot reach in to cancel it — the workflow record is terminated, but the external task runs to completion and its result is discarded. This exception does not apply to other node types: container scans, AI calls, and integration calls running on platform workers are actively cancelled

Updated: 2026-05-13