Cross-project delivery health dashboard for Azure DevOps

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.