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.
Frequently asked questions
What engineering metrics matter beyond DORA?
DORA measures delivery outcomes but says little about the conditions producing them. The gaps worth filling are PR cycle time (where delivery delay actually accumulates), flaky test count (which silently erodes trust in CI), alert response rate (whether monitoring is being acted on or ignored), and time to first merge for new joiners (the clearest signal of onboarding friction). Each is a leading indicator, whereas DORA's four keys are largely lagging.
Are DORA metrics enough on their own?
They are the right starting point and an incomplete picture. DORA tells you deployment frequency fell without telling you that one reviewer went on leave and PRs began queueing. The four keys are outcome measures, so by the time they move the cause is weeks old. Pair them with a small number of leading indicators and DORA becomes a scoreboard you can actually act on rather than a quarterly surprise.
How many engineering metrics should a team track?
Fewer than most teams do — roughly five to eight actively watched. The constraint is attention, not data collection: a dashboard with thirty metrics gets glanced at and nothing gets acted on. A useful filter is whether anyone would change a decision based on the number moving. Metrics that fail that test are worth collecting for diagnosis but not worth putting on the weekly report.
How do you measure engineering health without measuring individuals?
Keep every metric at team level and make that explicit. Individual PR counts and lines changed are trivially gameable and reliably produce the wrong behaviour — more, smaller PRs that add review overhead without adding value. Team-level cycle time, flaky test count, and stale PR percentage describe the system people work in rather than the people. The distinction is what keeps metrics diagnostic instead of evaluative.
