Start with current Azure DevOps status and the official Azure DevOps status portal. Read the product and geography in any notice. General Azure cloud status is not a substitute for Azure DevOps evidence.
A pipeline waiting to start may be constrained by its own organization, agent pool or deployment policy. Keep that possibility open even when another team reports a similar delay.
Capture the waiting message
Open the run and identify whether the wait occurs before an agent is assigned or between deployment stages. Save the run URL, queue time and exact message. Note whether the problem affects one pipeline, one pool or several unrelated projects.
| Waiting condition | Evidence to inspect |
|---|---|
| All suitable agents are occupied | Pool agent states and current jobs |
| Parallel-job capacity is exhausted | Running jobs and the organization's available capacity |
| No agent matches the job | Job demands and agent capabilities |
| A stage requires approval | The named approval or resource check |
| Several pools unexpectedly stall | Provider notices and the timing of the failures |
Microsoft's pipeline start troubleshooting guide identifies capacity, busy agents, unmatched demands and approvals as separate causes. Check which explanation your run actually reports before changing anything.
Separate capacity from agent availability
An online agent does not by itself prove a job can start. Review the parallel-job view for the relevant hosted or self-hosted capacity, then inspect the requested pool. If all capacity is occupied, identify the running work responsible for the wait. If a suitable agent is offline, involve its owner.
Changing a job's requirements merely to find an available machine can send work to the wrong environment. Record the requested pool and capabilities first, and preserve build requirements when making an approved correction.
Check the stage boundary
A deployment can wait on a resource approval or check rather than on an agent. Azure Pipelines evaluates checks before allowing a stage to proceed. Resource owners manage these controls; a YAML change is not a universal bypass. Microsoft's approvals and checks documentation explains the supported checks and where they are configured.
Ask the owner of the named resource to review a blocked check. Avoid disabling a deployment control just because the queue is long. Where an earlier run may already have changed production, establish its outcome before rerunning the deployment.
Escalate with a bounded statement
A useful report says which organization, project, pool and stage are affected; when the delay began; and what the run says it is waiting for. Include a timezone and a link accessible to the recipient. Share organization and log details privately with your administrator or Microsoft support.
If a matching provider incident exists, link it and say which of its stated effects you observe. If there is no matching notice, say that the cause is not yet confirmed. Neither an empty status page nor a queue alone settles the diagnosis.
Get Azure DevOps provider alerts and review recent provider history. These alerts do not inspect private pipelines or establish the health of your organization's agents.