You cannot manage what you do not measure. A practical guide to the metrics that actually track technical debt — what to collect, where to get it, and what "healthy" looks like.
The foundational metric. TDR = (remediation cost ÷ development cost) × 100. It expresses debt as a share of what it would cost to fix relative to what it cost to build — the same denominator finance teams already think in.
| TDR band | Status | Recommended action |
|---|---|---|
| Below 5% | Healthy | Normal engineering hygiene — no dedicated allocation needed. |
| 5–10% | Manageable | Allocate 10–15% of sprint capacity to debt reduction. |
| 10–20% | Elevated | Allocate 20%+ of sprint capacity; consider a dedicated initiative. |
| Above 20% | Critical | Needs an executive-sponsored remediation plan. |
The four DORA (DevOps Research and Assessment) delivery metrics don't measure debt directly — but debt is very often the root cause behind a poor score on all four.
| Metric | Elite | Low | How debt shows up |
|---|---|---|---|
| Deployment frequency | On-demand (multiple/day) | Fewer than once / 6 months | Debt slows CI/CD pipelines and increases release risk, forcing batching. |
| Lead time for changes | Under 1 day | 1–6 months | Tight coupling forces multi-system changes and heavy review friction. |
| Change failure rate | 0–15% | 46–60% | Low test coverage and high complexity increase defect escape rate. |
| Mean time to recovery | Under 1 hour | 1 week – 6 months | Poor observability and tangled dependencies slow root-cause analysis. |
Source: Google / DORA State of DevOps, 2019–2024.
| Metric | Healthy target | What it tells you |
|---|---|---|
| Story points per sprint | Stable or growing | A sustained downward trend is the clearest velocity-decline signal. |
| Defect escape rate | Below 10% | Share of bugs found in production rather than pre-release. |
| Bug-to-feature ratio | Below 20% | Rising ratio means more time defending existing code than building. |
| Time-to-merge | Under 24 hours | Long review cycles often trace back to complexity and low confidence. |
| Metric | Healthy target | Typical source |
|---|---|---|
| Cyclomatic complexity | Under 10 per function | SonarQube, CodeClimate, static analysis |
| Code churn rate | Under 15% | GitHub / GitLab analytics |
| Test coverage by module | 60–80% | CI coverage reports |
| Dependency freshness | 80%+ on latest major/minor | Renovate / Dependabot dashboards |
Track 8 metrics monthly — enough to see trends, not so many that nobody looks at the dashboard. Split evenly between what engineering watches day-to-day and what the business needs to see.
Technical Debt Ratio (TDR)
DORA deployment frequency
Test coverage
Code churn rate
Annual debt cost
Velocity trend
Incident rate / MTTR
FTE wasted on debt
| Metric type | Typical source |
|---|---|
| Complexity, churn, coverage | SonarQube / CodeClimate / static analysis |
| Deployment frequency, lead time | GitHub / GitLab / CI-CD analytics |
| Incident rate, MTTR | Issue tracker (Jira, Linear) incident reports |
| Time spent on debt / workarounds | Team survey estimates (self-reported, quarterly) |
15+ metrics on a dashboard means nobody actually looks at it. Pick 8, review monthly, and add more only if a specific question demands it.
High coverage with weak assertions gives false confidence. Pair coverage with defect escape rate and team confidence surveys.
A snapshot score is far less useful than a trend line. Re-measure on a fixed cadence so the direction of travel is visible.
Metrics that don't connect to a specific decision (what to fix next, how much capacity to allocate) become theater. Tie every dashboard metric to an action threshold.