Developer metrics are measurements of how software gets built and delivered: how fast changes reach production, how often they break, how long pull requests wait, and how developers experience the work. The useful ones describe a team and its delivery system, not a single person. Start with the five DORA delivery metrics, add pull request cycle time and one or two developer-experience signals, and review them with your team rather than ranking people.
This guide covers which metrics are worth tracking, how to read them together, which habits make them misleading, and how to pick a small set you can act on this quarter.
TL;DR
- Measure the system and the team, not individual developers. Delivery depends on coordinated work, so individual scorecards mislead.
- DORA's five software delivery metrics are the best baseline: deployment frequency, change lead time, failed deployment recovery time, change fail rate and deployment rework rate.
- Add pull request cycle time, first-review time and build feedback time to see where work waits.
- Pair numbers with developer feedback, and treat every metric as an indicator, never a target.
- Start with two to four metrics tied to one improvement goal, then reassess.
Table of Contents
- What developer metrics are and what they can tell you
- The DORA metrics: your delivery baseline
- Workflow metrics: where work actually waits
- Quality and reliability metrics
- Developer experience: the numbers telemetry cannot give you
- Measuring the impact of AI coding tools
- Metrics that go wrong
- How to choose and use developer metrics
- Our perspective on metrics
- Where automation moves the numbers
- Try it on your own repositories
- FAQ
- Sources
What developer metrics are and what they can tell you
A developer metric is a number that describes some part of the path from idea to running software. McKinsey's overview of developer productivity describes measurement at system, team and individual levels. Outcomes such as deployment frequency or lead time show delivery results, while other measures point to places where you can optimize.
That last point is the useful one. A metric rarely gives you an answer. It gives you a question: why did lead time double in March? Why do half our pull requests sit for two days before anyone looks? The number tells you where to look, and the conversation with your engineers tells you what is actually happening.
Most useful developer metrics fall into four groups:
- Delivery: how quickly and safely changes reach users.
- Workflow: how work moves through review, build and merge.
- Quality and reliability: how often releases fail and how fast you recover.
- Developer experience: how the work feels, including friction, interruptions and focus.
The DORA metrics: your delivery baseline
DORA's research program is the most widely used reference for delivery measurement. Its current guide identifies five software delivery performance metrics, split between throughput and instability.
| Metric | What it measures | Group |
|---|---|---|
| Deployment frequency | How often you deploy to production | Throughput |
| Change lead time | How long a change takes to go from commit to production | Throughput |
| Failed deployment recovery time | How long it takes to recover from a deployment failure that needs immediate intervention | Instability |
| Change fail rate | Share of deployments that cause a failure in production | Instability |
| Deployment rework rate | How much unplanned, incident-driven deployment work you do | Instability |
The definition of recovery time matters. DORA defines failed deployment recovery time as the time needed to recover from a deployment failure requiring immediate intervention. A cosmetic bug fixed next sprint does not count.
How to read them together
The five metrics are a balanced panel, not five separate scoreboards. Throughput should improve without instability rising. If deployment frequency doubles while change fail rate climbs, you did not get faster, you moved the cost somewhere else. The same guide advises against optimizing a single metric, comparing across very different contexts, and turning measures into rigid targets.
That second warning is easy to miss. A payments service with strict change controls and a marketing site with continuous deploys should not share a benchmark. Compare each service with its own history.
Workflow metrics: where work actually waits
DORA metrics tell you the outcome. Workflow metrics tell you which stage is responsible. The ones that earn their place:
- Pull request cycle time: the time between two defined workflow events, such as PR opened to merged, or first commit to production. DORA's measurement guidance suggests measuring between defined events and inspecting delays at each stage.
- Time to first review: how long a PR sits before a human responds.
- Build and test feedback time: how long a developer waits to learn whether CI passed.
- Throughput: how many work items finish in a period.
- Work in progress (WIP): how many items are open at once. High WIP usually means slow everything.
The list of useful measures in DORA's guide includes all of these alongside SLO compliance and developer satisfaction.
A worked example
Say your median PR cycle time is 30 hours. That alone tells you little. Break it into stages:
- Open to first review: 18 hours
- Review to approval: 6 hours
- Approval to merge, including CI reruns: 6 hours
Now the problem is visible. Review pickup is the bottleneck, not coding speed and not CI. The fix might be a review rotation, smaller PRs or clearer ownership. Spending months on build speed would have changed very little.
The same stage-by-stage view applies to bug fixes. If an exception is reported in monitoring on Monday and the fix merges on Friday, ask how much of those four days was engineering and how much was waiting: for triage, for someone to pick up the ticket, for a failed check to be noticed. Waiting is usually the larger share, and it is the part you can shorten.
Quality and reliability metrics
Speed without stability is not progress. Alongside change fail rate and recovery time, teams commonly track:
- SLO compliance: whether your services meet the reliability targets you set for users.
- Error volume and age: how many unresolved production exceptions you carry, and how long they have been open.
- Revert rate: how often merged changes are rolled back.
Error backlog age deserves more attention than it gets. A growing pile of unresolved exceptions is a leading indicator: it tells you reliability debt is accumulating before it shows up in change fail rate or an incident. If you use an error tracker, a simple weekly chart of open issues by age is one of the cheapest quality metrics you can add.
Developer experience: the numbers telemetry cannot give you
System data cannot tell you whether engineers feel productive. The ACM Queue DevEx framework names three core dimensions of developer experience: feedback loops, cognitive load and flow state. Its authors recommend combining developers' perceptions with workflow and system data, because telemetry alone cannot fully expose the experience.
In practice that means a short, regular survey. Ask how long people wait for feedback, how hard the codebase is to understand, and how often they get uninterrupted focus time. Then compare the answers with your cycle time and build time data. When they disagree, the disagreement is the finding.
The SPACE framework takes the same broad view. According to McKinsey's summary, SPACE spans satisfaction and well-being, performance, activity, communication and collaboration, and efficiency and flow. DORA gives you delivery health, and SPACE reminds you that people and collaboration belong in the picture. They complement each other rather than compete.
Measuring the impact of AI coding tools
Most teams now want to know whether AI assistance is helping. DORA's guidance is practical: compare a baseline with similar AI-assisted and non-assisted work using cycle time, review effort, rework, reliability and developer feedback. It also recommends keeping your existing baselines and adding AI-relevant measures such as suggestion acceptance, trust and perceived productivity, instead of starting over.
The 2024 DORA report shows why both sides matter. It found that 75% of respondents reported productivity gains from AI in the prior three months. The same report estimated that each 25% increase in AI adoption was associated with a 1.5% drop in delivery throughput and a 7.2% drop in delivery stability. People felt faster while system-level numbers moved the other way. If you only measure perception, or only measure telemetry, you miss half of that story.
The practical lesson: do not count AI usage as a result. Suggestions accepted or tokens consumed describe activity. Track whether lead time, rework and fail rate improved on the work where AI was used.
Metrics that go wrong
Bad metrics rarely fail because the math is wrong. They fail because of how they are used.
Using team metrics on individuals
McKinsey notes that deployment frequency can assess systems or teams but is not suitable for evaluating individual performance, because delivery depends on coordinated contributions. One engineer who unblocks three colleagues may ship nothing and still be the most valuable person on the team that week. Commit counts, PR counts, lines of code and story points have the same flaw.
Turning indicators into targets
When a measure becomes a target, people optimize the measure. Set a goal of 10 deployments a week and you will get ten tiny deployments. DORA lists the common pitfalls: setting metrics as goals, relying on one metric, comparing disparate applications, siloing ownership, encouraging competition and measuring at the expense of improvement.
Trusting logs as automatically objective
Data from tools feels neutral. DORA's 2025 guidance warns that logs-based measures can be distorted by instrumentation differences, errors and interpretation bias. Two teams can define "deployment" differently and produce incomparable numbers. Write down your definitions before you start charting.
How to choose and use developer metrics
DORA's advice is to choose a framework based on organizational goals, collect baseline measures, act, check progress and adjust. Its list of candidate frameworks includes DORA's delivery metrics, SPACE, DevEx and H.E.A.R.T. LeadDev's guidance for introducing metrics adds that you should start with a small set tied to a specific improvement area, treat DORA measures as indicators and combine numbers with engineers' own feedback.
A workable first quarter looks like this:
- Pick one problem. For example: fixes take too long to reach production, or the error backlog keeps growing.
- Choose two to four metrics that describe it. Change lead time and PR cycle time for the first problem. Open error age and recovery time for the second.
- Define each one in writing. Which event starts the clock, which stops it, which repositories count.
- Capture a baseline for several weeks. Do not change anything yet.
- Share the numbers with the team. The same guidance recommends transparent definitions, team visibility and team ownership, and using metrics for insight rather than punishment.
- Make one change, then recheck. Reassess regularly and retire metrics that stop being useful.
By the end of the quarter you should know where work waits and have evidence that one change helped or did not.
Our perspective on metrics
We build software that opens pull requests to fix production errors, so we look at developer metrics from a specific angle: how much of your cycle time is waiting, not working?
When teams chart the path from an exception appearing in monitoring to a fix merged, the slowest parts are rarely the code change. They are the queue before someone triages the issue, the gap before someone notices a failed check, and the extra round trip when CI goes red. Those delays do not show up as effort, but they dominate lead time and recovery time.
That is why Cooper&Wright is designed to stay with a pull request from the first commit to a green, mergeable state. It watches the CI checks, fixes failures in iterative rounds, and hands the result to your team with context. Our aim is that engineers spend their time reviewing a ready PR instead of nursing one along. We publish a median merge time under 8 minutes as the result we aim for, and we put the pull requests themselves on a public proof page so the number can be inspected.
We also think a tool that touches your delivery metrics should respect how you read them. Every PR still goes through your review and your merge rules. When you override a fix, we learn from that override, so the next fix reflects how your team writes code. The goal is shorter waits and a smaller backlog, never a scoreboard of individual output.
Zack
Where automation moves the numbers
Once you have a baseline, you can see which stages automation can shorten. Three are worth watching.
Error backlog age. If production exceptions sit for days before anyone looks, an automated first fix cuts the wait before work starts. The metric to watch is the age of the oldest open issues, along with the median time from first occurrence to a merged fix.
CI failure rework. A pull request that fails checks, gets noticed hours later and needs a second push inflates PR cycle time. Tracking the number of review-and-fix rounds per PR shows how much of your cycle is rework.
Routine dependency updates. Small, repetitive pull requests, such as dependency bumps, can clog review queues and distort throughput counts. Separate them from feature work in your charts so they do not hide real trends.
Whatever tooling you use, keep the baseline from before you started. DORA's guidance to compare similar work with and without automation applies here exactly as it does for AI assistants. Compare like with like, and ask your engineers whether the change felt real.
If you are exploring how automated fixes work for the error tracker you already run, the ways a Sentry error gets fixed is a good place to start.
Try it on your own repositories
Cooper&Wright is a native GitHub and Sentry integration that opens a pull request for a Sentry error, monitors its checks, and iterates on failures for up to three rounds before escalating to your team. It also handles pull requests opened by humans and Dependabot, and it supports frameworks including Rails, Laravel, Django, FastAPI and Flutter.
Plans on our pricing page are $0 per month on the Free plan, built for open-source usage, $10 per month or $110 per year for Basic, and $50 per month or $550 per year for Pro, for private repositories. If you want to see what a finished fix looks like before you commit, browse the pull requests we opened.
FAQ
What are the most important developer metrics?
Start with DORA's five delivery metrics: deployment frequency, change lead time, failed deployment recovery time, change fail rate and deployment rework rate. Add PR cycle time and a short developer-experience survey. Together they cover speed, stability, workflow and how the work feels.
Can I use developer metrics to evaluate individual engineers?
It is not a good idea. McKinsey says deployment frequency suits systems or teams but not individuals, because delivery depends on coordinated contributions. Use metrics to find system bottlenecks, and judge individual performance through context, peer feedback and the work itself.
How many metrics should a team track?
Fewer than you think. LeadDev recommends starting with a small set tied to one improvement area. Two to four metrics with clear written definitions are easier to act on than a dashboard of twenty that nobody owns.
How do I measure whether AI coding tools are helping?
Keep your existing baseline and compare similar AI-assisted and non-assisted work on cycle time, review effort, rework, reliability and developer feedback. Do not treat usage numbers as results. DORA's 2025 guidance recommends adding measures like trust and perceived productivity to what you already track.
How often should we review our metrics?
Look at trends regularly with the whole team, for example in a monthly retrospective, and reassess which metrics still serve your goal every quarter. Retire any that people have started gaming or that no longer lead to decisions.
Sources
- How to measure developer productivity, McKinsey
- DORA's software delivery performance metrics
- Choosing measurement frameworks to fit your goals, DORA
- DevEx: What Actually Drives Productivity, ACM Queue
- Accelerate State of DevOps Report 2024, DORA
- Introducing engineering metrics to your organization, LeadDev