Azure DevOps monitoring

Azure DevOps monitoring across the Pipelines hub

YAML pipelines and Classic Release pipelines in one feed across every Azure DevOps project. DORA deduplicated across both pipeline products. Parallel-slot utilisation surfaced per row. Two-minute setup.

platform-api · Pipelines
web · Pipelines
desktop · Pipelines
notifications · Pipelines
admin · Pipelines
CI/CD Watch · All projects
cicd.watch/builds/reposslots: 4 / 6

Projects across 14 Azure DevOps projects · last 30 days

ProjectStatusLast runSuccess rate
platform-apihealthy4m ago
96%
webhealthy12m ago
91%
desktopflaky18m ago
78%
notificationshealthy1h ago
94%
adminhealthy3h ago
100%
checkoutbroken12m ago
62%

Pipelines · DORA · Flaky tests

Beyond the Pipelines hub

Three capabilities every CI/CD Watch tenant uses, each wired into how Azure DevOps reports data. YAML pipelines and Classic Release pipelines treated as one estate, with parallel-slot accounting throughout.

1

Pipelines, every project, one feed

The Pipelines hub works for one project. Sprawl breaks it.

Every pipeline run across every Azure DevOps project in your organisation, in one live feed. YAML pipelines and Classic Release pipelines shown together with a clear type tag. Drill straight back into the Azure DevOps run page when you need the raw logs.

  • YAML and Classic pipelines surfaced together with a yaml / classic tag
  • Parallel-slot consumption shown per row: how many of your purchased slots each run is using
  • Each row links straight to dev.azure.com/<org>/<project>/_build/results?buildId=<id>

Outcome: one view across the entire org, regardless of pipeline type.

What's needed: personal access token with read access. Nothing in your azure-pipelines.yml or Classic Release definitions changes.

cicd.watch/builds4 / 6 slots

Pipelines across 14 projects · live

CIyamlplatform-api · main · ubuntu-latest · 4m 12s
PR-validationyamlcheckout · feat/cart · 3m 08s
Release-Prodclassicweb · main · 6m 41s
Build-Windowsyamldesktop · pr-1284 · windows-2022 · 1m 32s
CIyamladmin · main · 5m 02s
Status, Project, Pipeline (yaml/classic), Branch, Trigger, Duration, Updated . Sortable, filterable.
2

DORA, deduplicated across YAML and Classic

Five DORA metrics, defensible mid-migration from Classic to YAML.

DORA metrics calculated from real pipeline run data. Azure DevOps is the only provider with two co-existing pipeline products. Mid-migration estates often have a YAML environment: deploy AND a Classic Release stage both shipping the same change. Without dedup, your deploy frequency doubles overnight.

  • YAML environment: and Classic Release stages both surface as deployments
  • Dedup rules link YAML deploys to their Classic counterpart so each logical deploy counts once
  • Trend over 7 / 30 / 90 days, per-project or aggregated, with period-over-period regression alerts

Outcome: DORA defensible even mid-migration from Classic to YAML.

What's needed: PAT. Auto-detection covers environment:; dedup rules take five minutes if you run both YAML and Classic.

cicd.watch/metrics

DORA by project · 30 days · ranked by deploy frequency

ProjectDeploysLead timeCFR
platform-api12.4/wk1h 48m8.2% ⚠
web6.1/wk2h 12m3.2%
notifications4.2/wk3h 04m5.1%
admin2.8/wk2h 41m4.0%
desktop1.7/wk5h 22m6.5%
web deploys link YAML environment:prod to the Classic Release-Prod stage as one logical deploy
3

Flaky tests, surfaced via PublishTestResults@2

PublishTestResults@2 already runs in most pipelines. We surface the flakes.

If your pipeline uses PublishTestResults@2 (most Azure DevOps pipelines do), the data is there. Each test gets a flip rate, failure rate, and current status so the most disruptive ones surface first.

Native task, most pipelines already have it

- task: PublishTestResults@2
  inputs:
    testResultsFormat: 'JUnit'
    testResultsFiles: '**/junit*.xml'
  • Per-test flip rate scored across branches over a rolling 30-day window
  • Failure rate and current status per test, sortable in the table
  • Matrix strategies (strategy: matrix:) merged per logical test, not duplicated per matrix leg

Outcome: fix the disruptive tests first, with real flip-rate data to triage them.

What's needed: PublishTestResults@2in your pipeline. Azure DevOps' native task, most teams already have it.

cicd.watch/stability/flaky-tests

Flaky tests, last 30 days, sorted by flip rate

TestFlip rateFailure rate
CheckoutFlow.confirmsOrder
platform-api · CI
14%6.8%
WindowsInstaller.signs
desktop · Build-Windows
11%5.2%
EmailQueue.deliversWithRetry
notifications · CI
9%3.9%
AuthMiddleware.refreshesToken
web · CI
6%2.1%
Test · Pipeline · Failures · Runs · Flip Rate · Failure Rate · Status . Sortable, filterable.

Same connect, more depth

How we work with Azure DevOps

Three more capabilities the same connect unlocks. None of them are Azure-DevOps-only, but each pays off particularly well on Azure DevOps estates where project sprawl, dual pipeline products, and parallel-slot pricing all shape what you're paying for.

Cost

Cost-optimization opportunities ranked by potential saving

Right-sizing recommendations, redundant-step detection, and waste categorisation. Parallel-slot utilisation factored in so the saving reflects what Azure actually bills.

Drop 2 parallel slots (38% utilisation)~$80/mo
Cache npm install in 6 pipelines~$60/mo
Cancel PR builds on new push~$45/mo
See cost opportunities

Audit

Audit rules catch CI/CD hygiene gaps across the estate

Built-in rules check for missing lint, no unit tests, absent SAST, secrets-in-config patterns, and more. Findings ranked by severity; each one names the project and the fix.

No unit tests4 projects
Classic pipeline only (no YAML)9 projects
PublishTestResults@2 presentAll projects
See audit findings

Strategy

Branching strategy auto-detected per project

Trunk-based, GitFlow, GitHub-flow detected from your real branch and merge patterns. DORA metrics get a per-strategy lens so trunk-based projects aren't penalised for not having long-lived release branches.

platform-apitrunk
webtrunk
desktopgit-flow
See branching detection

All from one connect

Plus the rest of the toolkit

The three capabilities above are what you'll use most. Same connect also gives you cost tracking, PR health, stability classification, performance ratings, security insights, Slack, CLI, and an MCP server. No extra integrations.

Cost tracking

Parallel-slot spend plus developer wait time. Waste auto-categorised by type. Team tier.

PR health

Per-project CI failure rates, reviewer wait time, and PR-to-deploy latency. Team tier.

Stability classification

Every pipeline auto-classified healthy, flaky, or broken. Trend detection on each.

Performance ratings

Per-pipeline performance scoring across the estate. Spot the slow outliers.

Security insights

Per-project security-scan detection rolled up across the estate. Business tier.

Slack notifications

Pipeline failures, regressions, and degradation alerts in your team channel. Team tier.

CLI

Query pipeline status, costs, and DORA from your terminal. Pipe it anywhere.

MCP server

Hook Claude, Cursor, or any AI agent into live pipeline state.

Pricing

Flat per tenant

Start free for one team. Team and Business tiers are flat monthly rates per tenant. Enterprise is custom for organisations needing SSO, audit logging, and security review.

Free

For one team getting started with up to 3 projects.

$0/month
Start free
  • 3 projects
  • 1 team member
  • Pipeline runs, DORA, flaky tests
  • Parallel-slot view (last 30 days)
  • Email support
Most popular

Team

Flat rate per tenant. Up to 20 projects and 10 team members.

$29/month
Start Team trial
  • 20 projects
  • 10 team members
  • Everything in Free
  • Cost tracking with full history
  • PR health, performance ratings
  • Slack notifications, CLI, MCP server

Business

Flat rate per tenant. Up to 100 projects and 50 team members.

$99/month
Start Business trial
  • 100 projects
  • 50 team members
  • Everything in Team
  • Audit findings and cost-optimization opportunities
  • Priority support

Comparison

How CI/CD Watch compares

A 10-person team running Azure DevOps across ~20 projects. Headline pricing only; deeper feature comparisons live on the linked pages.

CI/CD Watch$29 / mo flat (Team)
Datadog CI VisibilityFrom $8 / committer / mo + per-span overagesSee full comparison →
LinearB$29 / contributor / mo (Essentials, annual)See full comparison →
BuildPulseFrom $99 / mo (flat tier)See full comparison →
Cross-project pipeline feedLive, with parallel-slot use per rowYesLimitedYes
YAML + Classic Release dedupYes, one logical deployNoNoNo
DORA metrics from CI dataAll five, auto-detectedAdd-onYesNo
Cost tracking (compute + wait time)Yes, with parallel-slot contextCompute onlyWait time onlyNo
Pricing modelFlat per tenantPer committer + spansPer contributorFlat tiers
Setup time~2 min PATAgent install per repoOAuth + config~5 min

Competitor pricing reflects each vendor's published headline rate. See the linked comparison pages for fuller feature matrices and verified sources.

~2 min

to connect via PAT

0

agents to install in your agents

5

DORA metrics from day one

Flat

per-tenant pricing

FAQ

Azure DevOps specifics

How is this different from Azure DevOps' built-in analytics?
Azure DevOps Analytics works per project: build success rates, test trends, deployment summary. It stops at the project boundary, and Classic Release pipelines surface separately from YAML. CI/CD Watch is the cross-project lens with YAML and Classic deduplicated, parallel-slot consumption visible, and DORA aggregated across the whole org.
How do you handle the YAML vs Classic Release split?
Both surface in the same feed with a type tag. For DORA, deployment-detection rules link a YAML deploy to its Classic Release counterpart by build artifact reference so each logical deploy counts once. Mid-migration estates don't see their deploy frequency double overnight.
Will it eat into our parallel-slot allowance?
No. CI/CD Watch reads from Azure DevOps' API after pipelines complete. It does not run pipelines, install agents, or consume parallel slots. The polling is rate-limit-aware and stays under the published API limits using conditional requests.
How does it surface parallel-slot pricing?
Azure DevOps bills $40/parallel-slot/mo regardless of consumption. We show slot utilisation per workspace and queue waits per agent pool, so you know whether to buy more slots (queue wait climbing) or drop some (low utilisation).
Does it work with self-hosted agents?
Yes. Self-hosted runs surface in the feed with their agent pool label. If you've configured a cost rate for your self-hosted infrastructure under Settings, cost calculations apply that rate; otherwise self-hosted runs are tracked but not costed against Microsoft's rate card.
How long does setup take?
Around two minutes. Create a personal access token in Azure DevOps with read scopes on Build, Release, and Code, paste it into CI/CD Watch, pick which projects to include. The first pipeline feed populates within minutes.
Is pricing tied to parallel slots or seats?
Neither. CI/CD Watch is flat per tenant: $0 Free, $29 Team, $99 Business per month. Project and team-member caps differ per tier; consumption inside those caps is unmetered.
Can we get DORA across Azure DevOps and GitHub Actions or Jenkins?
Yes. Connect each provider separately; DORA metrics include runs from every connection. Useful for mixed estates mid-migration where part of the team has moved to GitHub Actions and part is still on Azure DevOps.
Azure DevOps Server (on-prem) or Cloud only?
Cloud only today. Azure DevOps Server connections sit behind your firewall and require additional networking config that's not yet in scope. If you're running Server, get in touch.

One feed across every project, both pipeline types.

Connect Azure DevOps in two minutes. YAML and Classic Release pipelines, DORA deduplicated, parallel-slot consumption visible per row.