Is Azure DevOps Down? Azure DevOps Status, Outages, and Your CI

Your CI just went red and you suspect Azure DevOps. Here is how to confirm an outage in seconds - and how to stop a service blip from failing your builds in the first place.

When Azure DevOps has a hiccup, every pipeline that depends on it can fail at once. The good news: these failures are transient, so the fix is to confirm the outage and make your CI resilient to it.

How to check if Azure DevOps is down

1. Check the official status page: status.dev.azure.com
2. Look for an active incident affecting Pipelines, Repos, Artifacts, or Boards.
3. Cross-check community reports (Downdetector, the project status on social/X).
4. Confirm it is org-wide, not just your job: if every repo that depends on Azure DevOps fails at once, it is an outage, not your config.

What it looks like in CI

An outage usually surfaces as a transient network or 5xx error while talking to Azure DevOps:

##[error]We stopped hearing from agent. Verify the agent machine is running
# or: TF400813: Resource not available (503)

Outage vs your own bug

• Outage: many repos fail at once, errors are network/5xx/timeouts, no recent change on your side.
• Your bug: one repo, a specific error, started right after a change you made.

How to keep CI green during a blip

• Add retry-with-backoff around the step that hits Azure DevOps - most blips pass within a minute.
• Mirror critical artifacts to a second feed and retry pipeline steps that hit Azure DevOps services.
• Cache dependencies and artifacts so a brief outage does not block jobs that could run from cache.
• Avoid mass "re-run all" during an incident - it piles up when the service recovers.

Key takeaways

• Check status.dev.azure.com first; org-wide failures = outage, not your config.
• Azure DevOps blips are transient network/5xx errors.
• Retries, caching, and a fallback keep CI green through a hiccup.

Frequently asked questions

Related guides