Merge pull request #8089 from MicrosoftDocs/users/sdanie/297486

Update MDP 2 day job limit

Author: prmerger-automator[bot]

docs/managed-devops-pools/configure-scaling.md

@@ -1,7 +1,7 @@
 ---
 title: Configure scaling
 description: Learn the different performance options for Managed DevOps Pools and their impact on agent performance.
-ms.date: 06/13/2025
+ms.date: 07/03/2025
 ---
 
 # Configure scaling
@@ -142,6 +142,9 @@ When **Same agent can be used by multiple builds** (`"kind": "stateful"` in reso
 
 * **Max time to live for standby agents** (`maxAgentLifetime`) configures the maximum duration an agent in a stateful pool can run before it is shut down and discarded. The format for **Max time to live for standby agents** is `dd.hh:mm:ss`. The default value of **Max time to live for standby agents** is set to the maximum allowed duration of seven days (`7.00:00:00`).
 
+   > [!IMPORTANT]
+   > If a job is running when the **Max time to live for standby agents** interval expires, the agent won't shut down until the job completes, unless the job takes longer than two days to run. Individual jobs in Managed DevOps Pools can run for a maximum of two days, even if they are running on a standby agent with more than two days configured for **Max time to live for standby agents**. Contact support if your workflow requires running a single job that takes more than two days to complete.
+
 * **Grace Period** (`gracePeriodTimeSpan`) configures the amount of time an agent in a stateful pool waits for new jobs before shutting down after all current and queued jobs are complete. The format for **Grace Period** is `dd.hh:mm:ss` and the default is no grace period.
 
 While agents in stateless pools are shut down and discarded after every job, agents in stateful pools continue running if any of the following conditions are met.
@@ -888,7 +891,7 @@ If you don't know your usage patterns and want to rely on automatic forecasting
 
 ## Lifecycle of agents and potential delays in allocation
 
-Standby agents using a [Stateless](#stateless-pools) scheme require the Azure Pipelines agent to be installed and configured before transitioning from the [ready](./view-agents.md#status) state to the [allocated](./view-agents.md#status) state and running a pipeline. When provisioning new agents, Managed DevOps Pools attempts to download the latest [Azure Pipelines agent](https://github.com/microsoft/azure-pipelines-agent/releases) in order to have it already downloaded on standby agents before they transition into ready status. Startup, connection, and beginning the job can take anywhere from 10 seconds to a minute depending on the pool's SKU speed, image used, and networking load. Additionally, certain settings in a pipeline job can cause a redownload and running of a different agent, and regressions and rollbacks of the agent can also cause a redownload of the agent. [Ready agents](./view-agents.md#status) will always have a potential delay, as Managed DevOps Pools uses this agent in an "ephemeral" manner, meaning we start and run the task agent one time per job.
+Standby agents using a [Stateless](#stateless-pools) scheme require the Azure Pipelines agent to be installed and configured before transitioning from the [ready](./view-agents.md#status) state to the [allocated](./view-agents.md#status) state and running a pipeline. When Managed DevOps Pools provisions new agents, it attempts to download the latest [Azure Pipelines agent](https://github.com/microsoft/azure-pipelines-agent/releases) in order to have it already downloaded on standby agents before they transition into ready status. Startup, connection, and beginning the job can take anywhere from 10 seconds to a minute depending on the pool's SKU speed, image used, and networking load. Additionally, certain settings in a pipeline job can cause a redownload and running of a different agent, and regressions and rollbacks of the agent can also cause a redownload of the agent. [Ready agents](./view-agents.md#status) will always have a potential delay, as Managed DevOps Pools uses this agent in an "ephemeral" manner, meaning we start and run the task agent one time per job.
 
 If you are seeing delays in ready agents picking up jobs from Azure DevOps, the following are important to consider:
 

docs/managed-devops-pools/overview.md

@@ -1,7 +1,7 @@
 ---
 title: Managed DevOps Pools Overview
 description: Learn about Managed DevOps Pools.
-ms.date: 03/25/2025
+ms.date: 07/03/2025
 ms.topic: overview
 #Customer intent: As a platform engineer, I want to understand the benefits of using Managed DevOps Pools.
 ---
@@ -21,7 +21,7 @@ Manage DevOps Pools:
 * Has agents in the geographical region closest to your dependencies
 * Scales up and down based on your configuration
 * Can maintain state of your agents up to seven days, so your builds are faster due to cache hits 
-* Can run long running workflows up to two days long
+* Can run long running workflows up to two days long. Contact support if your workflow requires running a single job that takes more than two days to complete.
 * Can access resources in your company network or isolate your workload to only access specific endpoints
 * Can create agents that have the same software as Azure Pipelines Microsoft-hosted agents
 * Can view all active agents and the status of agent provisioning and reimaging