# Cross-project delivery health dashboard for Azure DevOps

> See work items, pull requests and pipeline health for every Azure DevOps project on one screen, with stalled reviews and repeat build failures flagged.

- Workflow type: app
- Services: Azure DevOps
- Categories: Engineering, Operations
- Published: 2026-08-14

## What it does

- Opens on an organization-wide overview with a row per project, plus tiles showing work in flight grouped by state, open pull requests bucketed by how long they have been waiting, and the share of pipeline runs that passed over the last two weeks.
- Click any project to drill into three tabs: active work by assignee, every open pull request with its age, target branch and reviewers, and recent pipeline runs with their results.
- Flags pull requests left open more than three days as stalled and highlights pipelines that have failed more than once in a row, so problems stand out instead of hiding in a list.
- Lets you re-run a failed build straight from the pipelines tab, and every row deep links back to the original item in Azure DevOps. Each person picks the projects they care about and that choice is remembered between visits.

## What you'll need

- An Azure DevOps account with access to the projects you want to track
- Permission to view work items, repositories and pipelines in those projects
- Permission to queue builds, if you want to re-run failed pipelines from inside the app

## Prompt

Build me one delivery health screen that shows work items, pull requests and builds together across all of my Azure DevOps projects. The built-in analytics only covers boards, so it cannot tell me anything about repos or pipelines in the same view, and that is the whole reason I need this. Azure DevOps is the only integration.

The app opens on an organization overview built from List Projects, with a row per project and a set of tiles across the top. The tiles show work items in flight grouped by state using Query Work Items (WIQL), open pull requests bucketed by age, and pipeline pass rate over the last two weeks. Each project row summarizes the same three signals so I can scan the whole organization at once.

Clicking a project drills into three tabs. The work tab lists active items by assignee, using Query Work Items (WIQL) to find the matching ids and then Get Work Items Batch to pull the fields it needs to render each row.

The code tab walks List Repositories and then List Pull Requests per repo, showing every open pull request with its age, target branch and reviewers. Flag anything open more than three days as stalled. Average teams wait 19 or more hours before a review even starts, and pull requests eat roughly 30 percent of cycle time, so surfacing the stalled ones is the point of the tab.

The pipelines tab uses List Pipelines together with List Pipeline Runs and List Builds to show recent runs, highlighting definitions that have failed more than once in a row. From this tab I want to re-run a failed build directly with Run Pipeline or Queue Build, then confirm the requeued build with Get Build so the row reflects its new status. Every row across all three tabs deep links back into Azure DevOps.

Each user picks which projects they care about, and that selection is remembered between visits so the overview opens filtered to their projects rather than the entire organization.

Build notes. Every request needs an api-version parameter. List endpoints page via $top with a continuation token returned in the x-ms-continuationtoken response header. WIQL returns ids only, so work item details must be fetched in batches of up to 200. There is a limit of 200 throughput units per user per five minute window, so fan-out across many projects and repos should be batched and cached rather than refetched on every render.

## How to customize

- Change the stalled pull request threshold from three days to whatever your team treats as too slow
- Adjust the pipeline pass rate window from two weeks to a shorter or longer period
- Change how the work tab groups items, for example by assignee, state or work item type

## FAQ

### Why not just use the dashboards built into Azure DevOps?

The built-in analytics views only cover Azure Boards work item data. They exclude repositories and pipelines, so pull requests and build results cannot appear in the same view. This app pulls all three together on one screen.

### Does this work across several projects at once?

Yes. The overview lists every project you have access to in the organization, with a row each and totals across the top. Rolling up multiple projects this way normally requires a higher plan or a separate reporting tool.

### Can I actually re-run a failed build from here, or is it read only?

You can re-run a failed build directly from the pipelines tab, as long as your Azure DevOps account has permission to queue builds. Everything else in the app only reads data.

### Will everyone on my team see the same projects?

No. Each person chooses which projects they want to follow, and that selection is saved for the next visit, so a team lead and an individual engineer can each keep their own view.

### What counts as a stalled pull request?

Any pull request that has been open for more than three days is flagged as stalled. That default reflects how long reviews typically sit before anyone picks them up, and you can change the threshold to match your team.

Use this prompt in General Input: https://www.generalinput.com/prompts/cross-project-delivery-health-dashboard-for-azure-devops