# Stop and Error

> End a run on purpose with a message explaining why, so it shows up as a failure rather than finishing quietly.

**Stop and Error** ends a run on purpose and marks it failed.

> Dock: Flow · Returns: nothing

Use it where a workflow has reached a situation it should not carry on from. Data that did not check out, a record that came back empty, a permission that is missing. The run then shows up as a problem rather than quietly finishing.

![The Stop and Error step selected on the canvas, with an error message written into its settings.](/images/docs/action-steps/stop-and-error-step.webp)
*Write the message the run stops with. Leave it blank and the step uses the standard one.*

```mermaid
flowchart LR
    A[Receive Webhook] --> B{Data Valid?}
    B -->|Yes| C[Process Data]
    B -->|No| D[Stop and Error]
```

## Setting it up

When a run reaches this step, it stops immediately.

### Place the Step
Add the **Stop and Error** step at the end of a branch where execution should not continue: the ELSE route of a validating Condition, or a Switch's fallback.

### Configure the Error Message

Enter a descriptive error message. It appears in the workflow's Execution logs, so your team can see why the run was aborted.

### Attach the data that caused it

Optional. Add the values that made the run stop, such as the record ID, the amount, or the status code. They are stored on the failure. When you open the run a week later, the message says what went wrong and this says which record it happened to.

## An empty branch looks like success

Leave a branch empty and the run registers as **Completed** when it reaches the end of it. Add a Stop and Error step, and it registers as **Failed** instead. That matters because:

- Somebody gets notified. Failed runs raise workspace error notifications; completed ones do not.
- The run history tells the truth, so a week of quiet failures does not read as a week of clean runs.
- Your message is on the failure, so whoever opens it knows what went wrong without reading the canvas.

## What it passes on

Stop and Error returns no output. It records the message and any attached data on the failed run so your team can diagnose it from the execution log.

## Limits

The step ends the current branch immediately. Any downstream steps connected after it do not run, so place notifications or cleanup work before Stop and Error or on an error-handling path.

## Examples to copy

### Reject a record that fails validation

Place Stop and Error on the ELSE route of a Conditions step. Use a message that names the rule and include the record ID as attached data:

```text
Customer record failed validation: email address is missing
```

### Make a Switch fallback visible

Place Stop and Error on the fallback route when every expected value has its own case. Include the value that did not match so the execution log shows what needs a new route.

## What's Next?

- Decide which failures should retry before they halt in [Error Handling & Retries](/build/core-concepts/error-handling).
- Catch unhandled cases on a fallback branch with the [Switch Step](/build/action-steps/switch).