--- sourceDocument: Australia IT Service Management sourceDocumentLink: https://www.servicenow.com/docs/r/australia/it-service-management Release : - australia ft:locale : - en-US ft:publication_title : - Australia IT Service Management ft:clusterId : - itsm bundleId : - itsm workflow : - Technology --- # Restarting failed build or release pipeline jobs and stages # Restarting failed build or release pipeline jobs and stages {#ariaid-title1} Release version: Australia Updated March 12, 2026 ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 minutes to read Summarize ![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete. ## Summary of Restarting failed build or release pipeline jobs and stages This feature enables ServiceNow customers to rerun failed or canceled Azure DevOps build or release pipeline jobs and stages within the same pipeline execution. Instead of creating new pipeline executions, reattempts appear as continuous runs in the DevOps pipeline UI, streamlining failure recovery and maintaining execution context. Show full answer Show less ## Key Features * **Rerun Options:** Customers can rerun entire pipelines or specific failed/canceled jobs and stages. * **Attempt Tracking:** An `attemptNumber` parameter tracks rerun attempts and must be included in the payload when using Azure Invoke REST API for configuration. If omitted, it defaults to 1. * **Change Request Reuse:** When rerunning change-enabled jobs, customers can choose to reuse existing change requests or create new ones via the base system subflow `DevOps Change Request Reusability Decision Subflow`. By default, change requests in the implement or post-implement state are reused; otherwise, new change requests are created. * **Associated Data Updates:** Each rerun updates associated test summaries, software quality scan results, commits, and work items in ServiceNow DevOps to reflect the latest attempt. * **Customizability:** Customers can customize the change request reuse logic by copying and modifying the provided subflows and updating their references in DevOps Properties. * **Pipeline UI Enhancements:** The DevOps pipeline UI now shows rerun attempts as continuous runs, provides links to view all attempts for repeated steps or stages, and displays the associated change requests for the latest attempts. ## Key Outcomes * Improved efficiency in handling failed builds or releases by rerunning within the same execution context. * Clear visibility of all rerun attempts and their associated data in the DevOps pipeline UI, aiding in diagnostics and audits. * Greater flexibility with change request management by enabling reuse or creation on reruns, minimizing administrative overhead. * Consistent and accurate tracking of pipeline execution attempts, test results, and quality scans, enhancing pipeline reliability and traceability. **Important Note:** Do not use existing started and completed notifications for stage jobs, as this breaks the rerun functionality. Also, ensure the `attemptNumber` parameter is correctly implemented in your REST API payloads to enable proper attempt tracking. Rerun or redeploy Azure DevOps build, release changes, or pipelines that are failed or canceled in that stage or pipeline. The reattempts display on the DevOps pipeline UI as continuous runs instead of creating new executions. ## Rerun Azure DevOps pipelines or stages {#restart-pipeline-stage-devops-ado__section_hcs_vvq_sqb} You can rerun a failed or canceled build or release pipelines or change jobs in Azure DevOps. The reruns are processed as part of the same pipeline execution as the first run in ServiceNow DevOps. You can rerun entire pipelines or specific failed or canceled jobs and stages. You can now choose to reuse a change request instead of creating a new change request each time you restart a stage or a pipeline. An attemptNumber parameter is added to the payload which helps us track reruns. Associated test summary, software quality scan results, commits, work items corresponding to every rerun attempt is also updated in ServiceNow DevOps. If you are using the [Configuring change control using the Azure Invoke REST API](https://www.servicenow.com/docs/JvdgAhTA1AeBK7OYJ7ZpHw "You can use the Azure Invoke REST API in your YAML or Classic Azure pipeline to configure change control for DevOps.") you must add the attempt number parameter to your payload body in the specified syntax format for build and release pipelines. If you do not specify the attempt number parameter, the default attempt number is set to 1. Example attempt number parameter in build pipeline payload: "attemptNumber": "$(system.jobAttempt)"​ Example attempt number parameter in the release pipeline payload: "attemptNumber": "$(Release.AttemptNumber)" Note: Do not use the existing started and completed notifications for the stage jobs. If your jobs consider the started and completed notifications the rerun functionality does not work. ## Reusing Change Requests {#restart-pipeline-stage-devops-ado__section_z4z_plk_sqb} If a change enabled job is rerun, and a change request exists for the previous run/attempt, you can choose to reuse the previous change request or create a new change request, using the base system 'DevOps Change Request Reusability Decision Subflow'. The default implementation of this subflow, allows you to reuse a change request from the previous attempt if the change request is in implement, or post-implement states. If the Change request is in any other state, by default, a new change request is created when you rerun the job. Per existing behavior, all associated details such as test summaries, and scans, are newly generated while commits and work items are retained unchanged for new change requests. For example, when a pipeline fails at a specific stage after the change request is approved, and you rerun that stage, the change request is reused. The associated test summary and software quality scans, the commits and work items associated to the artifact are associated with the same change request which you approved. To apply a custom logic for reusability, you can copy the existing subflow, make the changes, publish it, and update the new subflow name under DevOps PropertiesDevOps Change Request Reusability Decision Subflow. In the regular base system flow when a change is created, ' [Customizing DevOps flows](https://www.servicenow.com/docs/qL5ZkK2bE2766F_f0ltR7w "Customize or recreate the DevOps Change Request Manual Approval, DevOps Change Request Minimal Automation Approval, and DevOps Change Request Advanced Automation Approval flows based on your requirements using a flow or a script.")' is used to update the  State  field of step execution record after a decision is taken on the change request. However, when you reuse a change, the first trigger condition of a change request being created is not met. A base system subflow 'DevOps Change Request Reusability Model Subflow' is triggered instead, whenever a change request is reused when a job is a rerun. The default implementation of this subflow is similar to the DevOps Model Change Request flow. You can create a custom subflow and update the subflow name at DevOps PropertiesDevOps Change Request Reusability Model Subflow. ## Pipeline UI changes {#restart-pipeline-stage-devops-ado__section_mdt_zkq_sqb} ServiceNow DevOps synchronizes all the changes that are caused when you restart or rerun a stage or a job, and displays them in the DevOps pipeline UI. * Click a card to view the latest attempt of that stage. * Click the View all attempts link to see all the step executions and related information associated to the step or stage that is run more than once. * The View change link displays the change request associated with the latest attempt. {#restart-pipeline-stage-devops-ado__ul_dmb_1xm_vqb}In previous releases, failed jobs were either ignored or a new pipeline execution job was created for reruns and processed accordingly. For more information, see [DevOps Pipeline UI](https://www.servicenow.com/docs/yaj2dQuVNc7UKuimbU8Fug "Use the Pipeline UI to visualize interactions and results across a pipeline execution. This graphical view shows pipeline step progression and other details for each pipeline."). *[\>]: and then