> 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/release-orchestration/use-release-orchestration/release-orchestration-execution/error-handling.md).

# Error Handling

Learn how to handle failures and input-required steps during execution

During release execution, activities can fail or pause while waiting for input. When this happens, you need to decide how to proceed. The execution view and activity execution history provide the context you need to choose the right action: retry the activity, ignore the failure, or fix the underlying issue before continuing.

### What you will learn from this topic <a href="#what-you-will-learn-from-this-topic" id="what-you-will-learn-from-this-topic"></a>

By the end of this topic, you will be able to:

* [Retry](#retry) an activity after a transient failure.
* [Ignore](#ignore) a non-critical failure and continue execution.
* [Fix and continue](#fix-and-continue) after resolving an underlying issue.
* Recognize when an activity is [on hold or waiting for input](#on-hold-input-required).

### Retry <a href="#retry" id="retry"></a>

The retry action is your go-to option when a failure appears to be transient or when you have already addressed the underlying issue. When you retry an activity, it re-runs with the same configuration and inputs as the original attempt.

This works well for temporary problems like network timeouts, service unavailability, or other issues that might resolve themselves on a second attempt.

If the root cause has been resolved, for example, you fixed a configuration issue or a dependent service came back online, the retry succeeds, and the release continues normally. The retry action is logged in the execution history, so you can track how many attempts were made and whether the issue was resolved.

### Ignore <a href="#ignore" id="ignore"></a>

Sometimes an activity failure does not need to block the rest of the release. The ignore action lets you skip a failed activity and proceed to the next activity in the sequence. This is useful when an activity is non-critical for the rest of the execution, or when the failure does not impact downstream activities.

When you ignore a failed activity, it is marked as skipped or ignored in the execution status, but the action remains visible in the execution history for full traceability. This ensures you have a complete record of what happened, even though the release continued past the failure.

For example, if a pipeline activity fails but you know it is not required for the release to succeed, you can ignore it, and the release moves on to the next activity without stopping.

### Fix and continue <a href="#fix-and-continue" id="fix-and-continue"></a>

When you need to correct an underlying issue before the release can proceed, the fix-and-continue workflow gives you the flexibility to address the problem and then resume execution. This is the right choice when the failure indicates a real problem that needs to be resolved, not just a transient issue.

The typical flow works like this: first, you fix the underlying issue, which might involve updating a pipeline configuration, correcting a deployment script, or resolving a dependency problem. If the fix requires different inputs than those originally provided, you can update them through the Input Store.

Once the issue is resolved and inputs are updated if needed, you retry the activity, and the release continues from that point.

This approach lets you address real problems without restarting the entire release, saving time and preserving work that has already been completed successfully.

### On hold/input required <a href="#on-hold-input-required" id="on-hold-input-required"></a>

Some activities enter an "on hold" or "input required" state during execution. This happens when the activity needs human intervention before it can proceed. Manual activities that require approvals or sign-offs naturally enter this state, but other activities might also pause if they need additional information that was not provided at release start.

When an activity moves to this state, the system can send notifications to the relevant owners or approvers, alerting them that their input is needed. These notifications include context on what is needed and provide a direct link to the activity, so recipients can provide the required input quickly.

Once the input is provided, whether it is an approval decision, additional configuration, or information needed to proceed, the activity can continue, and the release resumes execution.

This state is different from a failure because the activity has not actually failed; it is waiting for the necessary input to continue. The release remains paused until the required input is provided, giving you control over when execution proceeds.

### Related topics <a href="#related-topics" id="related-topics"></a>

* [Executing a release](/release-orchestration/use-release-orchestration/release-orchestration-execution/executing-a-release.md)

{% @harness-feedback/feedback %}