> 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/executing-a-release.md). # Executing a Release Learn how to execute a release and monitor its progress This guide walks you through the complete release execution process, from starting a release to monitoring its progress and handling any issues that arise along the way. Understanding how execution works helps you effectively manage releases and respond quickly when intervention is needed. ### What you will learn from this topic By the end of this topic, you will be able to: * Understand [what release execution is](#what-is-release-execution) and how it follows your process definition. * Learn the available options for [starting execution](#starting-execution), on-demand, scheduled, or pre-execution. * Use the [release execution page](#monitoring-execution), including the Graph and Activity History tabs, to track release, phase, and activity status. * Respond to [failures and input-required steps](#handling-failures-and-input-required-steps) during execution. * Recognize the possible [completion](#completion) statuses for a release. ### What is release execution? Release execution is the process of running a release according to the phases, activities, and dependencies you have defined in your release process. When you execute a release, the system follows your process definition step by step, running activities in the correct order and respecting their dependencies. During execution, you can track what is happening at multiple levels. The release level shows you the overall progress, while phase and activity views give you detailed insight into what is running, what is completed, and what is waiting for input. This multi-level visibility helps you understand exactly where your release is in the process and identify any bottlenecks or issues that need attention. ### Execution start options You have flexibility in when and how you start a release execution. On-demand execution starts the release immediately upon triggering, which works well for urgent deployments or when you are ready to proceed right away. Scheduled execution lets you plan ahead by setting a specific date and time for the release to begin automatically. This is useful for coordinating releases with maintenance windows or ensuring releases happen during business hours. If you have scheduled a release but need to start it earlier than planned, you can use pre-execution to begin the release before its scheduled time. This gives you the planning benefits of scheduling while maintaining the flexibility to move forward when everything is ready. ### Execution monitoring Once a release enters the running state, you gain real-time visibility into what is happening. Open the release to see its execution page. The header shows the release version, name, and status (for example, **In Progress**), along with who triggered it. Select **View Release Inputs** to see the inputs provided for this execution, **Download Report** to export a release report, or **Burn Release** to stop the release. The release execution page has the following tabs: **Configuration**, **Graph**, **Approvals**, **Events**, **Deployments**, **Activity History**, and **Changesets**. **Status monitoring** The monitoring interface provides status information at multiple levels to help you understand the release's current state. The overall status shows the release's current state: whether it is running, has succeeded, has failed, or is on hold waiting for input. This high-level view gives you an immediate sense of whether the release is progressing normally or needs attention. At the phase level, you can see which phases have completed successfully, which are running, and which are waiting for approval or other manual input. This helps you understand the release's progress through its major stages and identify where it might be paused or blocked. **Graph** The **Graph** tab shows a card for each phase, with a pill at the top right showing how many phases are running in total. Each phase card shows the phase name and ID, its status (for example, **Running**), how many activities are completed with a **View** link, an owner avatar, a timestamp, and an **Inputs/Outputs** link. Use the **Phases / Activities** toggle at the bottom of the tab to switch between phase-level and activity-level views.
Release execution page, Graph tab, showing a phase card with its status, activities completed, owner, and Inputs/Outputs link
**Activity History** The **Activity History** tab lists every activity in the release, with filters for **Phase**, **Status**, and **Type**. The table shows the activity, its underlying pipeline or task, **Status** (for example, **On Hold** or **Running**), **Type** (**Pipeline** or **Manual**), **Start Date**, **End Date**, and who retried or ignored it. This history gives you the most granular view of what is happening, and a complete record of each activity's execution, including any errors that occurred in specific pipelines or activities, which is invaluable for troubleshooting. ### Failure and input-required step handling When an activity fails or requires input, the release does not necessarily stop. You have several options for how to proceed. The error handling system provides actions that let you respond appropriately based on the situation. If an activity fails due to a transient issue, you can retry it without making any changes. This works well for network timeouts, temporary service unavailability, or other issues that might resolve themselves on a second attempt. For failures that are not critical to the release's success, you can choose to ignore the failure and continue execution, allowing the release to proceed even though that particular activity did not complete. When you need to fix an underlying issue before continuing, the fix-and-continue option lets you address the problem and resume execution from where it left off. This is useful when you have identified the root cause and can resolve it quickly, avoiding the need to restart the entire release. Manual activities require human input before they can proceed, and these appear as "on hold" or "input required" in the execution status. When activities enter this state, the overall release process shows a message indicating how many activities require your input, and notifications are sent to the designated approvers or users. These inputs might include approval decisions, additional information needed beyond what was provided at the start of release, or fixes for issues discovered during execution. ### Completion Releases are complete and include one of several possible statuses, depending on how execution proceeded. A Success status means all required phases have been completed successfully, indicating the release has achieved its intended outcome. A Failed status indicates that at least one critical phase failed and no recovery action was applied, meaning the release did not complete as intended. If your release process is modeled to allow partial success, you might see a PartialSuccess status. This occurs when some phases succeed while others fail or are skipped, which can happen in complex releases where not all components need to succeed for the release to be considered acceptable. Understanding these completion statuses helps you determine whether a release achieved its goals and what follow-up actions might be needed. ### Related topics The following topics provide related information. * [Activity Execution Flow](/release-orchestration/use-release-orchestration/release-orchestration-activities/activities-overview.md#activity-types) * [Error handling](/release-orchestration/use-release-orchestration/release-orchestration-execution/error-handling.md) {% @harness-feedback/feedback %}