> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/harness-platform/3.0/harness-platform-resources/overview/strategy/on-failure.md).

# On failure

Configure what Harness does when a stage or step fails — abort, retry, ignore, or mark as success.

The **On failure** setting defines how Harness responds when a stage or step fails. By default, a failure aborts the rest of the pipeline. You can override this individually on any stage or step.

## What you will learn

* The available failure actions: abort, retry, ignore, mark as success, manual intervention, and rollback
* How to target specific error types (timeout, connectivity, authorization) with individual failure rules
* How to configure retry with backoff and escalate to manual intervention after retries are exhausted
* How ignored failures affect the pipeline's final status

***

## Actions

| YAML value            | What happens                                                                                                                                                                                                                                          |
| --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `fail`                | Mark the stage as failed and stop the pipeline. This is the default.                                                                                                                                                                                  |
| `abort`               | Abort the pipeline immediately.                                                                                                                                                                                                                       |
| `ignore`              | Mark the stage as failed but continue running the next stage.                                                                                                                                                                                         |
| `success`             | Treat the failure as a success and continue the pipeline.                                                                                                                                                                                             |
| `retry`               | Re-run the stage up to a configured number of times before giving up.                                                                                                                                                                                 |
| `manual-intervention` | Pause execution and wait for a user to take action. Harness displays a popup with options: **Mark as Success**, **Ignore**, **Retry**, **Abort**, or **Rollback Stage**. If no action is taken before the timeout expires, the `timeout-action` runs. |
| `stage-rollback`      | Trigger the stage's rollback steps.                                                                                                                                                                                                                   |
| `pipeline-rollback`   | Trigger rollback across all stages in the pipeline.                                                                                                                                                                                                   |

***

## Error types

A failure strategy can target specific error types rather than applying to all failures:

| Error type              | Triggers on                               |
| ----------------------- | ----------------------------------------- |
| `all`                   | Any failure                               |
| `timeout`               | Stage exceeds its timeout duration        |
| `input-timeout`         | Input waiting for user response times out |
| `authentication`        | Authentication errors                     |
| `authorization`         | Authorization/permission errors           |
| `connectivity`          | Network or connectivity errors            |
| `verification`          | Verification step failures                |
| `approval-rejection`    | An approval step is rejected              |
| `policy-evaluation`     | Policy evaluation failure                 |
| `delegate-provisioning` | Delegate could not be provisioned         |
| `delegate-restart`      | Delegate restarted during execution       |
| `user-mark-fail`        | Stage was manually marked as failed       |
| `unknown`               | Unclassified errors                       |

***

## YAML

`on-failure` is a list of rules. Each rule specifies one or more error types and the action to take:

```yaml
stages:
  - name: deploy
    id: deploy
    on-failure:
      - errors:
          - all
        action: fail
    steps:
      - name: run
        id: run
        run:
          script: ./deploy.sh
```

### Retry with backoff

When `action` is `retry`, configure the number of attempts, the interval between them, and what to do if all attempts are exhausted:

```yaml
on-failure:
  - errors:
      - all
    action:
      retry:
        attempts: 3
        interval: 30s
        failure-action: fail
```

### Retry, then pause for manual intervention

If you want a human to decide after retries are exhausted, use `manual-intervention` as the `failure-action`. The pipeline waits up to `timeout` for input. If no one responds, `timeout-action` runs instead:

```yaml
on-failure:
  - errors:
      - all
    action:
      retry:
        attempts: 2
        interval: 15m
        failure-action:
          manual-intervention:
            timeout: 20m
            timeout-action: fail
```

Valid `timeout-action` values: `fail`, `ignore`, `abort`, `success`, `stage-rollback`, `pipeline-rollback`.

### Multiple rules

Different actions for different error types; rules are evaluated in order:

```yaml
on-failure:
  - errors:
      - timeout
    action: retry
  - errors:
      - all
    action: fail
```

***

## Pipeline status with ignored failures

When `action: ignore` is used and a stage fails, the pipeline status shows as **IgnoreFailed**, not `Success`. The pipeline completes and all subsequent stages run, but the final status reflects that at least one stage was ignored.

***

## Next steps

* Go to [Conditional execution](/harness-platform/3.0/harness-platform-resources/overview/strategy/conditional-execution.md) to skip a stage based on an expression.
* Go to [Timeout](/harness-platform/3.0/harness-platform-resources/overview/strategy/timeout.md) to set the maximum run time for a stage.
* Go to [Pipelines overview](/harness-platform/3.0/harness-platform-resources/overview.md) to review the pipeline model.