Skip to content
| Marketplace
Sign in
Azure DevOps>Azure Pipelines>Release Pipeline Monitor
Release Pipeline Monitor

Release Pipeline Monitor

Eric Dufur

|
3 installs
| (1) | Free
Monitors pending and recently completed YAML multi-stage pipelines with per-stage status, awaiting-approval state, and rule-based health findings. Includes a dashboard widget and a Pipelines hub.
Get it free

Release Pipeline Monitor

See what's pending, what's stuck, and what just deployed — at a glance.

A free, lightweight Azure DevOps extension that surfaces your YAML multi-stage (release) pipelines so you don't have to dig through Pipelines pages to find out which deployments are waiting on an approval, which stages failed overnight, and which release ran a moment ago. Adds a dashboard widget and a Pipelines hub — take your pick.

Features

  • Dashboard widget — counts of pending / running / failed / succeeded across all pipelines in the project, plus the top rule findings. Configurable per instance.
  • Pipelines hub ("Release Monitor") — a filterable table of recent runs with colored per-stage pills, ⏳ badges for awaiting-approval stages, and rule findings for every row.
  • Distinct mode (default on) — collapses noisy run histories so you see only the latest run per (pipeline, branch).
  • Awaiting-approval surfacing — runs blocked on a manual approval pin to the top and clicking a ⏳ pill takes you straight to the approval page.
  • Rule-based health evaluation — out of the box:
    • Stuck-awaiting-approval — flags approvals pending longer than a threshold.
    • Failed-stage — flags deployment stages that failed.
    • Stalled-in-progress — flags runs running longer than expected.
    • Partially succeeded — flags partial-success runs. Thresholds are configurable in the widget settings.

Who it's for

Engineering teams running YAML multi-stage pipelines on Azure DevOps Services who want a release-board-style overview without configuring third-party tools or building one in-house. Especially useful when:

  • Approvals are getting forgotten in someone's inbox.
  • Multiple branches deploy to the same environments and you need to see them on one screen.
  • You want a dashboard widget your team can glance at without context-switching.

Permissions and data handling

The extension requests only the vso.build scope (read access to builds, pipelines, and timelines). It reads run + timeline data via the Azure DevOps REST APIs to render the views — nothing is stored, no data leaves your Azure DevOps tenant, no telemetry is sent. Awaiting-approval detection is derived from in-progress approval checkpoint records in the run timeline, so no separate approvals scope is needed either.

Scope

Targets modern YAML multi-stage pipelines whose deployment stages bind to Environments. Classic Release Management pipelines are intentionally out of scope.

Configuration (widget)

Per-widget settings (right-click the widget → Configure):

Setting Description
Pipeline ID Restrict to one pipeline definition (blank = all in the project).
Lookback window (days) How many days of runs to include.
Max runs Upper bound on runs fetched per refresh.
Approval threshold (hours) Hours before a pending approval is flagged.
In-progress threshold (minutes) Minutes before a running deployment is flagged.

Frequently asked questions

What does the "Distinct" checkbox do? With Distinct enabled (default), the hub shows only the most recent run per (pipeline, branch) combination. If main was built eight times today, you see just the latest one — useful for "what is the current state of each branch." Turn it off to see the full run history within the lookback window.

Why doesn't my pipeline show up? Most common reasons:

  • The pipeline hasn't run inside the lookback window (default 7 days).
  • It's a Classic Release pipeline, not a YAML multi-stage pipeline — Classic Release isn't supported (different API surface, intentionally out of scope).
  • You don't have read permission on the pipeline. The extension uses your own session via the vso.build scope, so you'll only see what you can already see natively in Pipelines.
  • The widget is scoped to a specific Pipeline ID. Clear that field in the widget configuration to monitor every pipeline in the project.

Is any of my data sent anywhere? No. The extension runs entirely in your browser using your existing Azure DevOps session and reads via the standard REST APIs. Nothing is stored, no telemetry is sent, no third-party services are contacted from inside the extension. (The only non-ADO request on this listing page is the Buy Me a Coffee button image.)

Does it work with Classic Release Management pipelines? No. Only modern YAML multi-stage pipelines whose deployment stages bind to Environments. If you're using Classic Release, this extension won't help — the underlying APIs are different.

Does it work on Azure DevOps Server (on-prem)? The manifest targets Microsoft.VisualStudio.Services, which is the cross-product target covering both cloud Services and Server 2022+. Development and testing happen against Azure DevOps Services (cloud); on-prem support is best-effort. If you hit something on Server, please open an issue with your Server version.

How often does the data refresh? The hub fetches on load and on demand via the Refresh button — there's no automatic polling, to keep API quota usage minimal and predictable. The widget re-renders whenever the dashboard reloads or its configuration changes.

What's the difference between "Awaiting approval" and the "stuck-awaiting-approval" finding? The Awaiting approval state pins a run to the top of the hub and adds the ⏳ badge whenever an approval checkpoint is currently in progress — that's pure observation. The stuck-awaiting-approval finding is a separate rule that fires only when the approval has been pending longer than the configured threshold (default 4 hours). One says "something needs a human"; the other says "and they've been waiting too long."

How do I customize what gets flagged? In the widget configuration (right-click the widget → Configure) you can set:

  • Approval-pending threshold (hours)
  • Run-in-progress threshold (minutes)
  • Pipeline scope (single pipeline or all in project)
  • Lookback window (days)
  • Max runs

The hub currently uses the default rule thresholds. Per-hub configuration is a candidate for a future release — if you'd find it valuable, please open a feature request.

Why does clicking the pipeline name take me to the repo, not the run? Two distinct links per row:

  • Pipeline name opens the source-code browser for the repo that ran.
  • The smaller #<buildNumber> underneath opens the run results page.
  • The colored stage pills open the run with that stage focused; an ⏳ awaiting-approval pill takes you to the run results page where the Approve banner appears.

Where do I report bugs or request features? GitHub issues: github.com/edufur/pipeline-release-monitor/issues.

Source and support

  • Source code: https://github.com/edufur/pipeline-release-monitor
  • Issues / feature requests: https://github.com/edufur/pipeline-release-monitor/issues
  • License: MIT — see LICENSE

Support the project ☕

If this extension saves your team a few headaches, you can support continued development:

Buy Me a Coffee

(This is an independent project — not affiliated with Microsoft or my employer.)

  • Contact us
  • Jobs
  • Privacy
  • Manage cookies
  • Terms of use
  • Trademarks
© 2026 Microsoft