How to Measure Technical Debt
Updated 26 March 2026
You cannot manage what you cannot measure. Before you can calculate the cost of technical debt or build a case for paying it down, you need objective signals that quantify it. Here are the metrics and tools that give you real numbers.
Code Quality Metrics
Cyclomatic Complexity
Measures the number of independent execution paths through a function. A score above 10 per function is a warning sign; above 20 is a debt signal that the function is too large and too coupled to test safely. High complexity means more cognitive load per developer and more edge cases per bug fix.
Tools: SonarQube, CodeClimate, ESLint (complexity rule), Radon (Python), NDepend (.NET)
Target: below 10 per function; below 5 for critical paths
Code Coverage
The percentage of production code executed during automated test runs. Low coverage is a direct proxy for hidden debt: every uncovered line is a future bug that reaches production undetected. Coverage below 60% on core business logic is a material risk. Coverage alone is not sufficient; the quality and assertions of tests matter equally.
Tools: Jest (JavaScript/TypeScript), pytest-cov (Python), JaCoCo (Java), Coverlet (.NET), Istanbul
Target: above 80% on business logic; above 60% overall for legacy systems
Code Duplication Rate
The percentage of code that appears in two or more places. Duplicated code means bug fixes must be applied in multiple locations, and changes in one copy do not propagate to others. Duplication above 5% at a codebase level indicates systematic debt from copy-paste development patterns.
Tools: SonarQube (duplications metric), CPD (Copy Paste Detector), Simian, JSInspect
Target: below 3% duplication; zero tolerance for duplicated business logic
Dependency Age and Vulnerability Count
The age of third-party libraries in use and the number with known CVEs. Outdated dependencies are debt that compounds over time: the longer a major version upgrade is deferred, the larger and riskier the eventual migration. Unmaintained dependencies with CVEs become security incidents waiting to happen.
Tools: Dependabot, Snyk, npm audit, OWASP Dependency-Check, Renovate
Target: no critical CVEs unpatched; no dependencies more than 2 major versions behind
Operational Metrics
Build and Test Pipeline Duration
Track the p50 and p95 build time over the past 6 months. A build time growing faster than team size is a debt signal. Every extra minute on a CI pipeline multiplies across every pull request.
Measure in minutes. Flag if p50 exceeds 10 mins for most teams.
Time to First Review (TTFR)
How long after a PR is opened does the first review comment arrive. High TTFR indicates reviewer avoidance of complex, risky, or poorly understood code, which is itself a debt symptom.
Measure in hours. Flag if median TTFR exceeds 24 hours.
Change Failure Rate
The percentage of deployments that cause a production incident requiring a hotfix or rollback. High change failure rates correlate directly with brittle, debt-heavy architecture.
DORA metric. Elite: below 5%. High debt: above 20%.
Mean Time to Recovery (MTTR)
How long it takes to restore service after an incident. Debt increases MTTR by making root cause analysis harder and remediation riskier due to unknown side effects.
Elite: below 1 hour. High debt: above 24 hours.
Deployment Frequency
How often the team ships to production. Debt reduces deployment frequency by increasing the risk and effort of each release. Debt-heavy teams often shift to large batch releases which carry higher risk.
Elite: multiple per day. High debt: weekly or less.
Onboarding Time to First Contribution
How many days until a new engineer ships their first production change. Long onboarding is a direct measure of codebase complexity and documentation debt.
Target: first PR within 2 to 3 days. Debt signal: above 10 days.
Team Friction Surveys
Quantitative metrics capture what the code looks like; surveys capture what developers actually experience. Both are necessary. Run a short quarterly survey with these five questions scored 1 to 5:
- 1How confident are you that a change in one area will not break something unexpected elsewhere? (1 = no confidence, 5 = high confidence)
- 2How long does it take you to understand an unfamiliar part of the codebase well enough to make a change? (1 = days, 5 = under an hour)
- 3How often do you find yourself writing a workaround instead of a proper fix because the proper fix is too risky? (1 = constantly, 5 = almost never)
- 4How much of your sprint do you spend on unplanned bug fixes or rework versus new features? (1 = most of it, 5 = very little)
- 5How would you describe the test suite quality? (1 = tests barely exist or are broken, 5 = comprehensive and trustworthy)
Score: 20 to 25 is healthy. 12 to 19 is significant debt. Below 12 is critical. Track the trend quarterly; a declining score predicts future attrition.
Turn your metrics into a dollar figure
Once you have your debt percentage estimate, use the calculator to see the annual cost.