This article is based on practical experience from an IBM engineering team and draws on research from the book Accelerate by Nicole Forsgren, Jez Humble, and Gene Kim. Original source: techbeacon.com.
Why DevOps Metrics Matter
Many engineering teams struggle to identify the key performance indicators (KPIs) that demonstrate to management why DevOps matters and how it affects business results. Without the right metrics, DevOps initiatives often stall or fail to gain organisational support.
Visualising objective, automated metrics makes them easier to understand and act on. The six metrics below have been used successfully by an IBM engineering team. For each one, we cover what it measures, why it was chosen, and the improvements it drove.
1. Availability and Uptime
In Accelerate, one of the four key software delivery metrics is time to restore service. Uptime is a way to aggregate that metric over time, giving stakeholders a single number that captures the reliability of each production service.
How to calculate it:
Availability = (Total Time - Total Outage Time) / Total Time × 100%An availability dashboard can compute this on demand for any date range, pulling outage data from your primary production monitor for each service.
Recommended SLOs: Most services at the IBM team referenced here committed to 99.95% uptime, with some committing to 99.85%.
When a senior leader reviews uptime numbers quarterly, teams are motivated to:
- Ensure their production monitors accurately reflect the real end-user experience
- Prioritise improving availability for services that are missing their SLO
- Celebrate when goals are met, reinforcing positive behaviour
2. Work in Progress (WIP)
The Toyota Production System and lean manufacturing established a core principle: limiting work in progress (WIP) improves overall throughput. It is better to finish one project today than to start ten and finish none.
A WIP metric is straightforward to implement: count the number of open issues of each type (story, defect, task) at any given time. When the count climbs too high, the team pauses new intake and focuses on completing what is already started.
Practical impact: Adding WIP to a team dashboard surfaces hidden bottlenecks and helps engineering managers have data-driven conversations about prioritisation and team capacity.
3. Repository Speed (Pull Request Cycle Time)
Pull requests represent value waiting to be delivered to production. Repository speed measures the average time from pull request submission to merge over a rolling 30-day window.
Example scoring scale:
- 0–2 weekdays average review time → perfect score (green)
- 2–5 weekdays → degraded score (yellow)
- 5+ weekdays → failing score (red)
Old pull requests are easy to lose track of, especially across multiple repositories. Displaying all outstanding pull requests on a single dashboard—highlighting aged ones—lets squads review the backlog during their daily stand-up.
Deeper insight this metric reveals: If multiple teams are consistently working on the same pull request, it may signal a tight coupling between services or a code-ownership problem. Well-designed APIs should allow each squad to deploy independently without coordinating changes with other squads. When this metric deteriorated, it pushed teams to experiment with:
- Pair programming
- Feature branch development
- API versioning
- Cross-repository code contributions
4. Deployment Frequency
Deployment frequency is one of the four key metrics in Accelerate and one of the most revealing indicators of DevOps maturity. Teams that deploy frequently:
- Recover from outages faster because they have battle-tested deployment automation
- Deliver value to customers more often
- Can patch critical security vulnerabilities in days, not weeks
Example scoring scale (over 30 days):
- 0–1 deployments → red
- 2–3 deployments → yellow
- 4+ deployments → green
Promoting More Frequent Deployments
Teams initially pushed back against this metric, citing monthly or biweekly release schedules. Using the research from Accelerate helped make the business case for more frequent deployments.
Practical changes that moved the needle:
- Moving teams to a weekly sprint cadence with regular playbacks made it immediately visible which teams were shipping value each week
- Sitting with a team for a few days to set up a CI/CD pipeline from scratch unblocked teams that lacked automation
- A red deployment frequency tile became a cue to audit the repository for unpatched security vulnerabilities and automate scanning
5. Deployment Stability (Build Success Rate)
Deployment stability measures the percentage of time the most recent build for a given repository was successful. This metric was invented by a developer on the team after colleagues reported spending too much time fixing broken builds.
Example scoring scale:
- 0–50% success rate → red
- 50–90% → yellow
- 90%+ → green
It is worth noting that not every broken build is a problem. A failing build that caught a defective change before it reached production is a sign that test automation is working. Builds become a problem when they stay broken for extended periods and block developer productivity.
Visualising build stability over time on a dashboard makes it obvious which squads need to invest time in clearing technical debt and stabilising their deployment pipelines.
6. Code Quality: SonarQube Metrics
Integrating SonarQube into your CI/CD pipeline gives teams automated scores for security, code quality, and test coverage. Displaying these at the repository, squad, and cross-platform level makes quality visible to everyone.
Real-world result: One team improved its SonarQube security score from a D to an A in two days simply by implementing the small, targeted fixes SonarQube recommended.
On test coverage targets: Setting a goal of 100% unit test coverage is intentionally aspirational. If a squad is comfortable with 70% coverage, they are free to accept the lower grade on the dashboard. The key is that the number is visible and the team makes a conscious, informed choice rather than ignoring coverage entirely.
On gaming the metric: It is theoretically possible to inflate coverage scores by adding coverage exclusions. In practice, this relies on developer and code-reviewer integrity—the same integrity required to write honest tests in the first place.
Start Small and Roll Out Gradually
The goal of a DevOps metrics dashboard is not to turn every tile green. The goal is to surface where a squad is performing well and where there is room to improve, so the team can make an informed decision about where to invest effort.
These six metrics are straightforward to visualise and have driven measurable improvements in the organisations that have adopted them. Recommendations for getting started:
- Pick one or two metrics first. Instrument availability and deployment frequency before adding the rest.
- Automate data collection. Manual dashboards decay quickly. Integrate directly with your monitoring, source control, CI system, and SonarQube.
- Make dashboards visible. Post them somewhere leadership and teams both see regularly—this creates healthy accountability without micromanagement.
- Use the data to start conversations, not assign blame. A red tile is an invitation to investigate, not a performance review.
- Revisit your thresholds. The scoring scales above are starting points. Calibrate them to your organisation’s context over time.
Further Reading
The four key software delivery metrics referenced throughout this article—deployment frequency, lead time for changes, time to restore service, and change failure rate—are covered in depth in Accelerate: The Science of Lean Software and DevOps by Nicole Forsgren, Jez Humble, and Gene Kim (IT Revolution Press).