What a technical debt scanner does

What these tools actually measure

A technical debt scanner parses your code into a syntax tree and measures properties of the resulting structure. It is not reading for intent. The measurements that carry most of the signal are consistent across tools:

• Cyclomatic complexity — the number of linearly independent paths through a function. It is a lower bound on the tests needed to cover every path, and a good proxy for how much a reader has to hold in their head before changing anything.
• Cognitive complexity — how hard the control flow is to follow. Nested conditions cost more than sequential ones, which cyclomatic complexity alone does not capture.
• Nesting depth and parameter count — cheap proxies for functions that have accumulated responsibilities rather than being designed with them.
• Dependency vulnerabilities — known advisories against the versions in your lockfile. Structural, in the sense that it is a fact about your dependency graph rather than a judgement about your code.

What they cannot measure

This is the part evaluation guides usually skip. A scanner cannot tell you that a module sits in the wrong bounded context, that an abstraction leaks, or that a simple-looking function encodes a rule nobody remembers agreeing to. Those are the expensive kinds of debt, and they are invisible to static structure.

What a scanner gives you is a ranked, repeatable starting point that does not depend on who happens to remember which files hurt. Treat the output as a shortlist for human judgement, not a verdict. A tool that claims to rank your architecture is overselling.

How to evaluate one against your own repository

Most scanners look equivalent on a marketing page and diverge sharply on real code. Four checks separate them quickly:

• Run it locally first — if evaluating requires granting a third party write access to your repositories, you are being asked to decide before you have evidence.
• Check the language coverage honestly — many tools count a language as supported when they can only count its lines. Ask which languages get a real parser.
• Ask how any effort estimate is derived — a number of hours that cannot be traced back to a formula is a number somebody chose. You should be able to reproduce it.
• Scan a file you already understand — the fastest credibility test there is. If the tool ranks a file you know is fine above one you know is painful, its model does not match your codebase.

How DebtDrone answers those four

DebtDrone runs twelve language-specific AST parsers — Go, JavaScript, TypeScript, Python, C#, PHP, Java, Ruby, Rust, Kotlin, Swift, and C/C++ — rather than counting lines and calling it coverage. Trivy adds dependency vulnerability and secret scanning to the same run when you enable it.

The effort estimate is a formula, not a guess: a function's estimate is the amount by which its cyclomatic complexity exceeds the threshold, multiplied by a fixed cost per point. Anything at or below the threshold carries none. The threshold is yours to set with --max-complexity; the cost per point is fixed, so every estimate on a report can be recomputed by hand.

# scan a directory and print a report in the terminal
debtdrone scan ./my-service

# machine-readable output, for piping into your own tooling
debtdrone scan ./my-service --format json

Nothing in that flow requires a DebtDrone account, and the CLI does not upload the scanned source. The quality-gate guide covers what changes when you want the same scan to run on every pull request.

Where the hosted product adds something

The CLI does keep a local scan history — debtdrone history list and debtdrone history show replay past summaries on that machine, and it is on by default. What it does not give you is a shared view: the history is local to one laptop, scoped to the scans that laptop ran.

That is the honest reason to connect a repository: hosted scans keep findings and grades across everyone's runs and every branch, so the trend belongs to the project rather than to whoever last ran a scan.

On Pro and Enterprise plans, supported pull-request events also update a single summary comment on the pull request and publish a commit status. Repository clones are deleted after each scan; findings retain the file path, the metrics, and a snippet of the code they point at, so the report can show you what was flagged. Full limits are on the pricing page.