Deploy & stability

What it measures

• Deploy cadence — releases per week, or merged-PRs-per-week as a proxy when the repo cuts no GitHub Releases.
• Change-failure rate — the share of merged PRs that are both classified as bug fixes and titled like a hotfix or a revert.
• Recovery time — median fix-time of those same PRs, shown only when any occurred.
• Lead time to release — merge-to-release time, shown only when the repo releases.

Why it matters

This is a deliberately light read on the DORA stability metrics — a quick health glance, not a DORA dashboard. It always shows something useful, even for teams that never cut a formal release.

How to read it

• The card shows a 2×2 scorecard of four tiles — each tile has a current-value numeral, a direction arrow (up/down/flat), and a mini trend sparkline. Metrics that are unavailable for the window are omitted.
• When there are no Releases, deploy cadence is a merge-count proxy — see Throughput for the same trend.
• Change-failure rate and recovery time are heuristic proxies from PR shape, not measured incidents.

Anti-blame

All values are repo/team-level rates; nothing here points at a person.

Common misreads

These are approximations of the DORA metrics, not the metrics themselves — dedicated tooling does that better. Treat them as a glance, not a verdict.

Change-failure rate sits far below Defect ratio, and that gap is the design, not a bug. A PR counts here only if it clears both gates — classified a bug fix and titled like a hotfix or a revert — so this number tracks emergencies, while Defect ratio tracks all fixing. Teams that mark incidents by label or linked issue rather than in the PR title will see a low number here regardless.