Managed DevOps Pool VMs stuck in "Starting" for ~2.5 hours in Sweden Central (2026-11-11) – root cause?

Hi @Nicolai Knudsen ,

Thank you for the detailed write-up. The timeline, metrics and VM size test made this much easier to review. I'm sorry your pipelines were held up for over two hours. That's frustrating, especially when nothing changed on your side.

1. Was there a platform-side issue in Sweden Central during that window?

Your evidence points to a temporary delay on the platform side, not a problem with your configuration:

• There were no configuration, image or agent changes before the incident.
• There were no failed requests or error codes. VMs were slow to come up, but they weren't rejected.
• Moving from D2ads_v5 to D2ds_v5 didn't help, so a single VM family or capacity pool wasn't the cause.
• The pool recovered by itself, and your burst test the next morning was normal.

Microsoft says the main Azure status page is used only for widespread incidents. Smaller or regional delays may not appear there. For Managed DevOps Pools, also check the Azure DevOps Status page. Earlier incidents affecting pipelines that use managed pools have been posted there. [azure.stat....microsoft] [azure.stat....microsoft] [isdown.app]

2. Can you see per-VM start diagnostics for a pool?

There's no boot-level log for each VM, but these options give you per-agent visibility:

• Agents view (Pool → Settings → Agents): Shows each agent's name, image, image version and status, such as Starting, Ready, Allocated or Returned. [learn.microsoft.com]
• Resource Provisioning Logs: Go to Monitoring → Diagnostic settings → Add diagnostic setting. This records each agent's provisioning event, including its name, image, SKU and status. You can archive the logs to a storage account or stream them to an event hub. They're stored in the MDPResourceLog table. [learn.microsoft.com] [learn.microsoft.com]
• TimeSpentInPreviousStateMs metric: Split it by PreviousState and NewState to see exactly how long agents stayed in "Starting" before becoming Ready. [learn.microsoft.com]
• Alerts: Set an Azure Monitor alert on the Starting count or AllocationDurationMs, for example when it goes above your normal 310,000 ms maximum, so you know early if this happens again. [learn.microsoft.com]

We'd recommend turning on Provisioning Logs now. They aren't collected until you turn them on, so there's no history to review for past incidents.

3. Is there a mitigation other than standby agents?

Microsoft's troubleshooting guide suggests these options for slow pipeline starts: [learn.microsoft.com]

• Stateful pool with a grace period: Agents stay online after a job and can be reused, so fewer new VMs need to start during a slowdown. Stateless agents are still recommended for security, so you might apply this only to non-sensitive pipelines. [learn.microsoft.com]
• Check Maximum agents and self-hosted parallel jobs: Make sure neither limit adds to the backlog when agents are slow to come up.
• Check time-out error codes in the pool's Overview metrics. [learn.microsoft.com]

For resilience against a slowdown in one region, we'd also suggest these:

• Backup pool in a second region, such as North Europe. For critical pipelines, switch the pool name or use a parameter so you can redirect quickly.
• Fallback to Microsoft-hosted agents for critical jobs that don't need private network access.
• Standby agents only during business hours if cost is the concern. A small number of agents kept ready at peak times would have absorbed most of the impact you saw. [learn.microsoft.com]

We hope this information is useful, and we're sorry again for the disruption.

Thank you

Please "Accept" the answer with an "Upvote" if the response was helpful. This will be benefitting other community members who face the same issue.