The four DORA metrics are the right baseline for delivery performance — but they're lagging indicators. They tell you a team is slow; they don't tell you why. These six health metrics surface the day-to-day friction that DORA only reflects after it has already cost you.
Start with DORA — but don't stop there
Deployment frequency, lead time, change failure rate, and MTTR are excellent outcome metrics. If you're not tracking them yet, that's step one (our 4-week DORA roadmap is a good start). But once you are, the natural next question — "what's actually causing our lead time to creep?" — needs metrics DORA doesn't provide. Here are six that do.
DORA Metrics Calculator
Start with your DORA tier
DORA is the foundation these metrics build on. Enter your four dimensions and see your tier — Elite, High, Medium, or Low — against the 2025 State of DevOps benchmarks.
The most actionable health metric there is. PR cycle time — open to merge, split into pickup, review, and merge phases — is a leading indicator of lead time. When cycle time creeps up, lead time follows a week later. Track median and P75 per repo so one slow team doesn't hide behind an aggregate.
2. Alert response rate
How many of the alerts your team receives actually get acted on? A low response rate is a sign of alert fatigue — and it predicts slow incident response, because the signal that matters is buried in noise the team has learned to ignore. If response rates sit below 50%, your MTTR is at risk regardless of how good your tooling is.
3. Flaky test count
The number of flaky tests in your suite is a direct measure of how much your team can trust its own CI. Each flaky test forces re-runs (inflating lead time) and erodes confidence in red builds (inflating change failure rate). A rising flaky count is an early warning that your stability metrics are about to degrade.
4. Onboarding time to first merge
How long from a new engineer's start date to their first merged PR? It's a sharp proxy for how much friction is baked into your environment — unclear setup, slow CI, opaque review process. Teams that have invested in reducing day-to-day friction onboard people in days, not weeks. (More on this in onboard new engineers faster.)
5. Code review quality, not just speed
Speed metrics can be gamed by rubber-stamping. Pair PR cycle time with a quality signal — review depth, defects caught in review vs. in production, or rework rate after merge — so "fast" doesn't quietly become "careless." We unpack the balance in code review quality vs. speed.
6. Incident recovery quality
MTTR tells you how fast you recovered; it doesn't tell you whether you recovered well. Track whether incidents get a blameless retrospective, whether the same incident recurs, and whether action items actually ship. A team with good MTTR but recurring identical incidents has a measurement blind spot.
How these fit together
These six aren't a replacement for DORA — they're the leading indicators that explain DORA's lagging ones. They also map cleanly onto the SPACE framework's Efficiency and Satisfaction dimensions; if you're weighing the two frameworks, see DORA vs. SPACE.
Deviera, an engineering intelligence platform, tracks most of these automatically. PR cycle time, flaky-test count, alert response, and the composite Friction Score all live in the value dashboard, computed from your existing GitHub and Vercel events — alongside the DORA four keys, so leading and lagging indicators sit side by side. For the full landscape, see our guide to engineering metrics.
