Technical Debt Tracking: Tools and Metrics That Work

Every engineering team accumulates technical debt. The difference between teams that ship reliably and teams stuck in a cycle of firefighting often comes down to one thing: technical debt tracking. Without a clear system to identify, quantify, and prioritize debt, it quietly compounds until it dominates your roadmap.

According to Jellyfish research, engineering teams spend between 23% and 42% of their development time dealing with technical debt. That is not a rounding error. That is nearly half your engineering capacity being absorbed by work that does not directly move the product forward.

So why do so few organizations track it well? And what does a working system actually look like?

I have spent the better part of a decade building and maintaining systems where debt was either invisible until it caused an outage or painstakingly cataloged in spreadsheets no one opened after the first week. Neither approach works. What follows is what I have found actually does.

Technical debt is not inherently bad. Every shortcut you take to hit a launch date is a bet: "We will come back and fix this before it causes real problems." Tracking is how you keep score on those bets.

Without tracking, three things happen predictably:

1. Debt becomes invisible. If it is not recorded anywhere, it only exists in the heads of engineers who wrote the original code. When they leave, the knowledge leaves with them.
2. Prioritization becomes political. Without data, conversations about "should we refactor this" turn into opinion wars between engineers who feel the pain and product managers who see the backlog.
3. Costs compound silently. Kong's research found that technical debt consumes roughly 40% of IT budgets. That number does not show up on any single line item. It is distributed across slower feature delivery, increased bug rates, and longer onboarding times.

The point of tracking is not to eliminate debt. It is to make informed decisions about which debt to carry, which to pay down, and when. That requires visibility.

For a deeper look at how visibility changes the conversation, see our guide on technical debt visibility.

Not all metrics are created equal. Some sound impressive in a slide deck but provide zero actionable information. Here are the ones that actually tell you something useful.

Code-level metrics:

• Cyclomatic complexity measures the number of independent paths through your code. High complexity correlates with higher defect rates and longer review times. Track it per module, not as an aggregate.
• Code churn rate tracks how often the same files are modified. Files that are changed in every sprint are either central to the product (fine) or poorly abstracted (not fine). Context matters.
• Dependency age monitors how far behind your dependencies are from their latest versions. Outdated dependencies are a security risk and a migration headache that only gets worse with time.

Flow metrics:

• Change failure rate measures how often deployments cause incidents. Rising failure rates often point to accumulated debt making the system more fragile.
• Cycle time trends show whether it is taking longer to ship similar-sized work. Kong's research shows that accumulated technical debt can reduce development speed by 30% or more.
• Bug clustering identifies which modules produce the most defects. Persistent bug clusters are a signal that the underlying code needs structural attention, not more patches.

Business-adjacent metrics:

• Debt ratio compares time spent on debt-related work versus new feature work over a rolling window. Track it monthly.
• Onboarding time by module measures how long it takes a new engineer to make their first contribution to a given area. Modules where onboarding takes disproportionately long often have the most accumulated debt.

The best tracking systems combine two or three metrics from different categories. A single metric in isolation can mislead you. Together, they paint a more accurate picture.

The tooling for technical debt tracking has matured significantly. Here is an honest assessment of the major categories.

Static analysis tools (SonarQube, CodeClimate, Codacy)

These tools scan your codebase and flag issues: duplications, complexity hotspots, test coverage gaps. They are good at identifying code-level debt and tracking it over time. Where they fall short is connecting that debt to business impact. A file with high complexity that is never touched is very different from one that is modified weekly.

Project management add-ons (Jira labels, Linear tags, custom fields)

Many teams start by tagging tickets as "tech debt" in their project tracker. This is better than nothing but introduces significant overhead. Engineers must remember to tag consistently, and the tags rarely capture enough context for prioritization. You end up with a long list and no ranking.

Engineering intelligence platforms (Glue, Jellyfish, Haystack)

These platforms pull data from multiple sources, including version control, CI/CD, project management, and code analysis, to provide a more complete picture. The advantage is that they correlate code-level metrics with delivery metrics automatically, so you can see how debt affects actual velocity.

Glue takes this a step further with AI-powered codebase intelligence. Rather than just flagging complexity scores, Glue maps how different parts of your codebase relate to each other, identifies ownership patterns, and surfaces debt in the context of what your team is actually working on. It connects the "what" (the debt exists) to the "so what" (it is slowing down this team's sprint goals).

Custom dashboards (Grafana + scripts, internal tools)

Some organizations build their own dashboards pulling metrics from various APIs. This offers maximum flexibility but requires ongoing maintenance, which is itself a form of technical debt. The irony is not lost on me.

For engineering leaders evaluating options, the right choice depends on your team's size and maturity. Teams under 20 engineers can often start with static analysis plus disciplined ticket tagging. Larger organizations benefit from platforms that automate the correlation work.

Tools alone do not solve the problem. You need a workflow that integrates tracking into how your team already operates. Here is a framework that I have seen work across multiple organizations.

Step 1: Define your debt taxonomy. Not all debt is the same. Categorize it: architecture debt, code quality debt, testing debt, dependency debt, documentation debt. Each category has different risk profiles and different remediation approaches.

Step 2: Automate what you can. Use static analysis and CI integration to automatically flag new debt as it enters the codebase. This is not about blocking merges (that creates its own problems) but about maintaining awareness.

Step 3: Establish a regular review cadence. Monthly debt reviews work well for most teams. Pull up your metrics dashboard, review the top debt items by impact, and make explicit decisions about what to address in the upcoming cycle.

Step 4: Allocate capacity intentionally. Many teams use a fixed percentage model, dedicating 15-20% of each sprint to debt reduction. Others prefer "debt sprints" where the entire team focuses on debt for a defined period. Both approaches work if leadership supports them. Neither works if debt reduction is always the first thing cut when deadlines tighten.

Step 5: Close the loop. After paying down a specific piece of debt, measure the impact. Did cycle time improve for that module? Did the bug rate drop? This data is what builds the business case for continued investment in debt reduction.

Stripe estimated that technical debt costs the global economy approximately $85 billion annually in lost developer productivity. That is a staggering number, but the more relevant question for your team is: how much is it costing you, and do you know?

Tracking is how you find out. It does not have to be perfect. It has to be consistent.

Get started with Glue to bring AI-powered visibility to your codebase and start tracking technical debt with real context, not just code scores.

What are the best tools for tracking technical debt?

The best tools depend on your team size and needs. Static analysis tools like SonarQube work well for code-level metrics. Engineering intelligence platforms like Glue provide broader visibility by correlating code metrics with delivery data, ownership patterns, and business impact. Most effective setups combine automated code scanning with a platform that provides context about how debt affects your actual work.

How do you measure technical debt?

Technical debt is best measured through a combination of code-level metrics (cyclomatic complexity, code churn, dependency age), flow metrics (change failure rate, cycle time trends), and business-adjacent metrics (debt ratio, onboarding time by module). No single metric captures the full picture. The goal is to combine two or three indicators that together show both the existence of debt and its impact on your team's ability to deliver.

What metrics matter for technical debt?

The metrics that matter most are the ones that connect code quality to business outcomes. Change failure rate and cycle time trends show how debt is affecting your delivery speed and reliability. Code churn and bug clustering identify where debt is concentrated. Debt ratio (time on debt versus feature work) gives leadership a clear picture of the tradeoff being made. Track consistently over time rather than optimizing for a snapshot.