> 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/use-harness-platform/pipelines/failure-handling/abort-pipeline.md).

# Abort a pipeline, stage, or step

Abort pipeline, stage, or step execution.

This topic explains how to stop an in-progress pipeline, stage, or step. Use this option with caution, as aborting an execution can have additional impacts.

***

### What you will learn from this topic

* How to [abort a pipeline](#abort-a-pipeline) to stop all running and queued stages.
* How to [abort a stage](#abort-a-stage) to stop a specific stage without affecting others.
* How to [abort a step](#abort-a-step) in certain step types.
* How the [pipeline abort process](#pipeline-abort-process) works and timing considerations.

***

### Before you begin

To abort a pipeline, stage, or step, you need permission to abort pipelines. There are two primary ways you can configure this with [Harness RBAC](/harness-platform/use-harness-platform/platform-access-control.md):

* **Pipeline Execute permission:** By default, this permission grants you the ability to initiate and interact with pipeline executions, including running pipelines, aborting pipelines and pipeline components (stages and steps), retrying/rerunning pipelines, and so on.
* **(Beta) Abort permission:** To control the **Abort** permission separately from other pipeline execute functions, you can enable the Feature Flag `CDS_PIPELINE_ABORT_RBAC_PERMISSION` by contacting [Harness Support](mailto:support@harness.io).
  * Enabling this feature flag can take several days because it requires migrating your existing users to this permissions structure.
  * If the **Abort** permission is not listed in your account's RBAC settings, then your account is using the default **Pipeline Execute** permission functionality to control all pipeline execution functions (run, abort, retry, and so on).

Permissions are contained in [roles](/harness-platform/use-harness-platform/platform-access-control/add-manage-roles.md), which can be narrowly scoped, such as the **Pipeline Executor** role, or broadly scoped, like the **Account Admin** role.

***

### Abort a pipeline

When you abort a pipeline:

* The pipeline finishes executing the current task and then stops.
* The pipeline status becomes **Aborted**.
* Harness does not clean up resources created during pipeline execution, such as pods.

{% hint style="warning" %}
Abort pipelines as a last resort. The abort action stops the pipeline execution and causes the pipeline to end execution in an aborted state. This prevents end-of-pipeline cleanup tasks from happening and can leave infrastructure in an unresolved state.
{% endhint %}

To terminate a running pipeline, go to the pipeline's execution details, select **More Options** (⋮), and then select **Abort Pipeline**.

![](https://173309742-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F3F2TpHXhur2QtQnORSM9%2Fuploads%2Fgit-blob-a8c4e506ef90a620b61827a2f85836d81ce29df9%2F1521187fad164055c77e9cbf28cf20ce38abb2a9f24d96b4a1d38b295402bfe2.png?alt=media)

### Abort a stage

When you abort a stage:

* The stage finishes executing the current task and then stops. Then the pipeline stops, and the pipeline status becomes **Aborted**. Stages after the aborted stage do not run.
* Harness **does not** clean up resources that were created during stage execution, such as pods.

To terminate a running stage in a running pipeline, go to the pipeline's execution details, select the stage you want to terminate, and select the **Stop** icon next to the stage name.

![](https://173309742-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F3F2TpHXhur2QtQnORSM9%2Fuploads%2Fgit-blob-f2fe341c303c0a351ce01f167f1955572a160c7d%2Fc30861565d02349af1a775fbeb5f673b1543f660d3e1905cf741686983a81a64.png?alt=media)

{% hint style="success" %}
To clean up the workspace and revert back to the old state, [mark the stage as failed](/harness-platform/use-harness-platform/pipelines/failure-handling/mark-as-failed.md).

<img src="https://173309742-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F3F2TpHXhur2QtQnORSM9%2Fuploads%2Fgit-blob-a2c5db13e491734dbb81262b4bbbfd09dad0a72c%2Ff2b19d998705a16884766f9fcd39d73baabc1dc6ed9b61b7dac5d284c29602f2.png?alt=media" alt="" data-size="original">
{% endhint %}

### Abort a step

You can initiate an abort on the **Verify** step. For more information, go to [Abort verification](https://developer.harness.io/docs/continuous-delivery/verify/configure-cv/abort-verification/).

### Pipeline abort process

Although an abort process may be initiated, there are multiple steps that need to be completed as a part of an abort. This can mean that delays can occur in the timing of when tasks become aborted, and whether the receiving environments will abort their processes.

As an example, a pipeline may have multiple parallel stages, doing a variety of tasks. A bash job, a build in Artifactory, and possibly other processes could be running concurrently.

They all may have different timings for when those abort process will be received and completed.

#### Abort completion process

The abort event to the delegate has its own delay due to network and infrastructure and can take time to arrive.

After that, the delegate still has the possibility of additional delays in sending that "abort" message to the destinations. Network and infrastructure can add further delays and then the abort process is also dependent on the task itself.

For example, aborting a BASH execution should be relatively simple, whereas, stopping a build process from Artifactory would be a larger process. Harness can initiate a command to abort, but it may ultimately be controlled by the other service that it is connecting to, and how it would handle the abort command.

During that time, the task that is supposed to be stopped can be completed or partially completed. Review your environments to confirm whether any artifacts or builds were created before the abort commands completed.

You should weigh whether aborting a pipeline or failing stages to trigger a rollback is a better option to stop execution.

***

### Next steps

You can now manually stop pipeline, stage, or step execution when needed. Aborting immediately terminates execution without triggering failure strategies.

* [Define failure strategies](/harness-platform/use-harness-platform/pipelines/failure-handling/define-a-failure-strategy-on-stages-and-steps.md): Configure actions when failures occur naturally.
* [Mark as failed](/harness-platform/use-harness-platform/pipelines/failure-handling/mark-as-failed-pipeline.md): Stop execution while triggering failure strategies.
* [Retry failed executions](/harness-platform/use-harness-platform/pipelines/failure-handling/resume-pipeline-deployments.md): Resume pipelines from failed stages.

{% @harness-feedback/feedback module="harness-ai" pagePath="harness-ai/use-harness-platform/pipelines/failure-handling/abort-pipeline" %}
