Team- and repo-level only, by design: no per-engineer metrics. Sign out
Headline
DORA delivery metrics (top row) paired with the PR-flow and pipeline metrics that drive them. Each tile is checked against the target in config.js. Review the trend monthly, not the absolute number weekly.
1 · PR flow: why PRs stay open
Open backlog, where the time goes between opening and merging, and how PR size affects it.
Open PR backlog over time
Open PRs at the end of each week, and how many of those were older than 7 days
Open PRs by age
Current open PRs, split by what each one is waiting on
Where the time goes (merged PRs)
Median hours per stage. Draft → ready → first human review → last approval → merged
Bigger PRs wait longer
Median open → merged time by PR size (lines added + deleted). Bar labels show PR count
Merged PRs per week and median cycle time
Bars: PRs merged. The median cycle time is in the tooltip and the trend chart beside this one
Cycle time and time to first review, weekly median
Hours, by the week the PR merged
2 · Pipeline: CI health
PR and branch checks (deploy workflows excluded). Slow or flaky pipelines push people to batch changes and rerun failures until they pass.
CI duration, weekly p50 and p90
Minutes per workflow run
CI pass rate and pass-on-retry rate, weekly
Pass-on-retry: run needed a rerun before it passed. This is a proxy for flaky tests
Slowest CI workflows
Least reliable CI workflows
3 · Path to production
Deploy workflows found from their names and paths. This is the starting point for mapping the release process: for each step, decide whether it is required for regulatory change control or accidental complexity.
Production deploys per week
Distinct (repo, commit) pairs deployed successfully. Multi-region fan-out counts once. Split by how the deploy was triggered
Merge → next production deploy
Merged PRs in repos with a detected prod pipeline, by how long they waited to reach prod
Release paths by repo
Manual steps are approximated by manual (workflow_dispatch) triggers, environment approval gates and the number of deploy workflows. Correct misclassified workflows in config.js → deployOverrides.
4 · Repo scorecard
One row per repo with activity in the window. Click a column to sort, or a repo name to filter the whole dashboard to it.
5 · Stale PRs to triage
Open PRs older than 7 days, oldest first. Each one needs a decision: review it, merge it, or close it.
Definitions and caveats
Cycle time: time from PR opened to merged. Time to first review: from ready-for-review (or opened, if never a draft) to the first review by a human other than the author. Bot reviews such as Copilot don't count. Calendar hours, not working hours.
Lead time for changes: time from PR opened to the first successful prod deploy run in the same repo at or after the merge. Merge → prod is the deploy-pipeline part of that alone. For release-train repos (version PRs or tags) this gives "the next prod release after merge", which is the time that matters.
Deploy frequency: distinct (repo, commit) pairs with a successful prod deploy run. The headline is the median across repos that have a prod pipeline and deployed at least once in the window.
Change failure rate (proxy): merged PRs whose title matches revert/hotfix/rollback, divided by prod deploys in the same repos. GitHub has no incident data, so connect incident tooling or Linear incident labels to measure this properly. Prod run failure rate (in the scorecard) is the share of prod deploy runs that failed.
Time to restore (proxy): from a failed prod deploy run to the next successful run of the same workflow.
CI: workflow runs on pull_request, pull_request_target, merge_group and push events that are not deploy workflows. Copilot and Dependabot dynamic workflows are excluded. Duration runs from run start to last update. Pass rate = success ÷ (success + failure + timed out). Cancelled and skipped runs are excluded.
Regulatory context (ISO 13485 / Class IIa): some friction on the path to production is deliberate change control. Don't compare lead time with generic SaaS benchmarks until the baseline is in. Aim to automate the compliance evidence (traceability, approvals, test records linked to the PR and pipeline), not to remove the controls. Tag the medical-device repos in config.js → regulatedRepos so you can compare the two release paths.
Freshness: each page load asks the server for the latest data. If the stored snapshot is more than a minute old, the server first fetches every PR and workflow run that changed since then from GitHub, saves the result, and serves it. Run ./seed.sh to do a full 90-day rebuild.