Tech Debt Metrics Dashboard Guide
What to measure, how to visualize it, and what the numbers actually mean for your engineering organization.
The Metrics Problem
Most engineering teams fall into one of two traps: they measure nothing, or they measure the wrong things. "We have 85% code coverage" sounds impressive until you realize half those tests are meaningless assertions that test nothing. "We closed 200 tickets last sprint" says nothing about whether the code got better or worse.
Coverage percentage alone is one of the most misleading metrics in software engineering. A team can have 95% coverage and still ship fragile, debt-ridden code. Conversely, a team with 60% coverage targeting critical paths might have a far healthier codebase.
The goal is not a wall of numbers. The goal is a dashboard that tells a story - a story about your technical health that connects directly to business outcomes. When your VP of Engineering asks "how healthy is our codebase?", you should be able to point to a single screen and explain the answer in 60 seconds.
The key insight: Good metrics connect engineering effort to business impact. If a metric does not help you make a decision or tell a story to stakeholders, remove it from your dashboard.
Tier 1: DORA Metrics (The Foundation)
The DORA (DevOps Research and Assessment) metrics are the industry standard for measuring software delivery performance. They are well-defined, widely benchmarked, and directly impacted by technical debt. Start here.
Deployment Frequency
How often your team ships to production. Elite teams deploy on demand, multiple times per day. Debt slows this down by making every change risky and requiring more manual testing.
Debt signal: If deployment frequency is declining quarter over quarter, debt is accumulating faster than you are paying it down.
Lead Time for Changes
Time from code commit to running in production. This measures the friction in your delivery pipeline. Debt adds friction at every stage - longer builds, more manual testing, complex deployment procedures.
Debt signal: Lead time increasing while team size stays constant means your codebase is getting harder to work with.
Change Failure Rate
The percentage of deployments that cause a failure in production requiring a hotfix, rollback, or patch. Debt increases this because tightly coupled, poorly tested code breaks in unexpected ways.
Debt signal: Change failure rate above 15% almost always indicates significant architectural or testing debt.
Mean Time to Recovery
How quickly your team recovers from a production failure. Debt complicates recovery because poorly structured code is harder to debug, and tightly coupled systems create cascading failures.
Debt signal: If MTTR is growing, your team is spending more time understanding the system than fixing it.
DORA Performance Benchmarks
| Metric | Elite | High | Medium | Low |
|---|---|---|---|---|
| Deploy Frequency | On demand (multiple/day) | Weekly to monthly | Monthly to quarterly | Less than quarterly |
| Lead Time | Less than 1 hour | 1 day to 1 week | 1 week to 1 month | 1 to 6 months |
| Change Failure Rate | 0-5% | 5-10% | 10-15% | 16-30% |
| MTTR | Less than 1 hour | Less than 1 day | 1 day to 1 week | 1 week to 1 month |
Source: DORA State of DevOps Report 2024-2025
Hypothetical Team DORA Profile
Compare your team's profile against elite performers and industry averages.
Higher values indicate better performance across all axes
Tier 2: Debt-Specific Metrics
DORA metrics tell you how fast and reliable your delivery is. Debt-specific metrics tell you why it is or is not improving. These metrics come from your backlog, sprint data, and issue tracking system.
Debt Ratio
The percentage of sprint capacity spent on technical debt work versus feature development.
Target: 15-20% planned allocation, less than 5% unplanned debt work
Debt Age
The average age of open technical debt items in your backlog. Older items are harder to fix because context fades and code evolves around them.
Watch for: Average age increasing quarter over quarter
Resolution Velocity
The number of technical debt items closed per sprint. This measures how fast your team is paying down existing debt.
Goal: Consistent or increasing velocity, not zero
Debt Creation Rate
New technical debt items logged per sprint. Some creation is normal and healthy - it means your team is identifying problems, not ignoring them.
Warning: Sudden spikes often follow rushed feature releases
Net Debt Trend
Resolution velocity minus creation rate. A positive number means you are paying down debt faster than creating it. This is the single most important debt metric.
Target: Positive number, consistently
P1 Debt Count
The number of critical-priority technical debt items currently open. These are items that pose security risks, cause outages, or block feature development.
Target: Zero. Always zero. No exceptions.
Tier 3: Team Health Metrics (Leading Indicators)
DORA and debt metrics are lagging indicators - they tell you what already happened. Team health metrics are leading indicators that predict future problems before they show up in your dashboards. When team health declines, DORA metrics follow 1-2 quarters later.
Developer Satisfaction Score
Quarterly anonymous survey, 1-5 scale. Ask about codebase quality, tooling, deployment confidence, and daily frustrations.
Benchmark: 3.5+ is healthy
Onboarding Time
Weeks until a new hire makes their first meaningful production contribution. High-debt codebases take 2-3x longer to onboard into.
Benchmark: 2-4 weeks is healthy
Voluntary Turnover Rate
Engineers who leave by choice. High-debt environments are the number one reason developers cite for leaving. Each departure costs 6-9 months of salary.
Benchmark: Below 15% annually
Unplanned Work %
The percentage of sprint capacity consumed by unplanned work - bug fixes, production fires, and emergency patches that were not in the sprint plan.
Target: Less than 20%
Code Review Turnaround
Average time from PR submission to first review. Slow reviews indicate either overloaded reviewers or code that is too complex to review quickly.
Benchmark: Under 4 hours
Developer Satisfaction vs. Debt Ratio
Teams with higher unplanned debt ratios consistently report lower satisfaction scores.
Hypothetical data based on industry survey patterns
Tier 4: AI Code Metrics (2026 Addition)
With AI coding assistants generating a growing share of production code, you need metrics that track AI-specific quality signals. Without these, AI-generated technical debt accumulates invisibly alongside the human-created kind.
AI-Generated PR Ratio
Percentage of pull requests that are primarily AI-generated or AI-assisted. Track this to understand your organization's AI adoption rate and ensure review processes scale accordingly.
AI Code Bug Rate vs Human Code Bug Rate
Compare defect density in AI-assisted code versus human-only code. If AI code has a significantly higher bug rate, your review process or prompt engineering needs attention.
AI Code Revert Rate
How often AI-generated code gets reverted after merge. High revert rates indicate that AI code is passing review but failing in production - a sign that your review process trusts AI output too much.
Hallucinated Dependency Count
Dependencies or API calls introduced by AI that do not actually exist or are deprecated. This should always be zero. Any non-zero value indicates a serious review gap.
Deep dive: For a complete framework on managing AI-generated code quality at scale, see our Managing AI Code Quality guide.
Building Your Dashboard: Practical Steps
You do not need to track everything on day one. Build your dashboard in layers, starting with the metrics that are easiest to collect and most impactful to share.
Start with DORA Metrics
Most CI/CD platforms (GitHub Actions, GitLab CI, Azure DevOps, Jenkins) can export deployment data natively. Tools like Sleuth, LinearB, Faros AI, and the DORA Quick Check can calculate these from your existing pipelines with minimal setup. You can be tracking DORA metrics within a week.
Add Debt Metrics from Your Backlog Tool
Tag existing backlog items as "tech-debt" in Jira, Linear, Azure DevOps, or whatever you use. Most tools let you create saved filters and charts for tagged items. This gives you debt ratio, age, and resolution velocity with no new tooling - just a label and a filter.
Survey Quarterly for Team Health
Keep the survey short - 5 to 8 questions maximum, anonymous, and actionable. Ask about codebase confidence, deployment anxiety, tooling satisfaction, and frustration sources. Use a 1-5 scale and track the trend over time, not individual scores.
Review Cadence
Review sprint-level metrics every two weeks with your team. Share monthly trends with engineering leadership. Present quarterly summaries to non-technical executives, translating metrics into business language. The dashboard is only useful if people actually look at it.
Anti-Patterns: Metrics That Hurt
Not all metrics improve outcomes. Some actively make things worse by incentivizing the wrong behavior. Remove these from your dashboard if you are tracking them.
Lines of Code
Incentivizes bloat. A developer who writes 50 lines of clean, well-tested code is more valuable than one who writes 500 lines of verbose boilerplate. Measuring LOC rewards the wrong behavior.
Replaced by: Deployment frequency + change failure rate
Coverage % Alone
Incentivizes meaningless tests. Teams that chase coverage numbers write tests that assert nothing useful. 95% coverage with weak assertions is worse than 60% coverage with mutation-tested critical paths.
Replaced by: Change failure rate + mutation test score
Bug Count Without Severity
Incentivizes not filing bugs. If "fewer bugs filed" is treated as a positive signal, developers stop reporting issues. A team with 200 tracked bugs is healthier than a team with 20 tracked bugs and 180 hidden ones.
Replaced by: Severity-weighted bug density + MTTR
Individual Developer Metrics
Creates competition instead of collaboration. Publishing per-developer commit counts, PR throughput, or review stats turns engineering into a performance contest. The developer helping three teammates debug all week shows up as "unproductive."
Replaced by: Team-level metrics + peer recognition
Frequently Asked Questions
Start with the four DORA metrics: deployment frequency, lead time for changes, change failure rate, and mean time to recovery. These are well-defined, widely benchmarked, and most CI/CD platforms can generate them automatically. Once those are stable, add debt ratio (percentage of sprint capacity on debt work) and net debt trend (resolution velocity minus creation rate). Those six metrics give you 80% of the picture with minimal overhead.
Most CI/CD tools like GitHub Actions, GitLab CI, and Azure DevOps can export deployment data natively. Third-party tools like Sleuth, LinearB, and Faros AI calculate DORA metrics from your existing pipelines with minimal configuration. If budget is tight, you can approximate with a shared spreadsheet tracking deploy dates, incident start and resolution times, and rollback events. It is not as automated, but it gets you started. Google's DORA Quick Check tool is also free and gives you a rough baseline.
Do not start with elite targets - that demoralizes teams. Benchmark your current state first, then aim for one tier improvement per quarter. If you deploy monthly, target weekly. If your change failure rate is 30%, target 20%. For debt metrics, focus on net debt trend being positive rather than hitting specific numbers. The goal is consistent improvement, not perfection. Celebrate moving from "low" to "medium" - that is real progress.
Translate everything into business language. Deployment frequency becomes "time to market for new features." Change failure rate becomes "customer-facing incidents per release." MTTR becomes "downtime cost per incident." Debt ratio becomes "percentage of engineering investment going to maintenance versus innovation." Always lead with the business impact number, show the trend line (improving or declining), and connect improvements to specific initiatives. Executives do not care about DORA - they care about shipping faster and breaking less.
Yes, with one important caveat: only team-level metrics should be public. Never publish individual developer metrics - that creates competition instead of collaboration. Put your dashboard on a TV in the team area or pin it in Slack. Review metrics in sprint retrospectives. When the whole team sees deployment frequency trending up, it creates shared pride. When change failure rate spikes, it creates shared ownership of the fix rather than blame.
Sprint-level metrics (DORA, debt velocity) should be reviewed every two weeks with the engineering team. Monthly trend reports go to engineering leadership showing quarter-over-quarter improvements. Quarterly executive summaries translate metrics into business outcomes for non-technical stakeholders. Daily monitoring should be automated with alerts for threshold breaches - especially P1 debt count (alert if above zero) and change failure rate (alert if above your target). The dashboard is a living tool, not a quarterly report.
Ready to Build Your Dashboard?
Start measuring what matters. Begin with DORA metrics this week, add debt-specific tracking next sprint, and build from there.