Slowpoke vs SonarQube
SonarQube belongs in your pipeline, and this is not an argument against it. But its technical debt is a static estimate derived from code smells, and nobody has ever believed the hours. Slowpoke measures what the debt costs in production, in a unit the business already understands.
The short answer
Which one you should pick
These measure two different debts that happen to share a name. One is about how the code reads; the other is about what the system does to the people using it.
Choose SonarQube if
You want the code itself held to a standard
- You want a quality gate in CI that fails a pull request on new issues.
- You want bugs, vulnerabilities, code smells, duplication and coverage across many languages.
- You need security static analysis — which Slowpoke does not do at all.
- You want a consistent standard applied to code nobody is running yet.
Choose Slowpoke if
You want the debt that is costing money right now
- You need to know which of your two hundred endpoints is actually wasting your customers' time.
- You want debt measured in seconds of waiting per day, not in an estimated number of hours.
- You need the worst offender identified with its query plan and the line of code that ran it.
- You need proof the fix worked, from production, not from a green badge in CI.
- You have to justify a performance sprint to somebody who does not read code.
Side by side
Slowpoke and SonarQube, line by line
Written to be fair, including where SonarQube is the better tool. If a row here is wrong or out of date, that is a bug: open an issue and it gets corrected.
| Aspect | Slowpoke | SonarQube |
|---|---|---|
| What it reads | The system that is running | Your repository |
| Unit of debt | Seconds of user waiting per day | An estimated remediation time in hours |
| Where the estimate comes from | Measurement | A rule's assumed cost per issue |
| Finds the slow endpoint | Yes, ranked | No |
| Finds the N+1 that is actually running | Yes, with the route and the count per request | Only if a rule happens to match the source |
| Query plans | Real EXPLAIN, twelve named diagnoses | — |
| Finds unused, dead or duplicated code | No | Yes |
| Security static analysis | Never | Yes |
| Test coverage | No | Yes |
| Proof a fix worked | Cost stays down for three measurement windows | The issue disappears from the report |
| Report for non-engineers | Effort, return per hour, budget, DORA | A quality gate and a rating |
| Runs in CI | No, it watches production | Yes, that is the point |
Two things are called technical debt
SonarQube's debt is a property of the source: a rule matches, the rule carries an assumed remediation time, the times are added up, and you get a figure in hours or days. It is a reasonable proxy for how hard the code will be to change, and it is a weak proxy for anything else. Nobody in a budget meeting has ever been moved by "we have 412 days of technical debt", because everyone in the room knows the number was assembled from assumptions.
Slowpoke's debt is a property of the running system, and it is measured rather than estimated: how long each endpoint, query, job and scheduled command actually takes, multiplied by how often it actually happens, divided by the period genuinely observed. The output is 4,911 seconds of customer waiting per day, and the next line says that 42 minutes of engineering removes 1,840 of them.
A rule cannot see how often the code runs
This is the structural limit, and it is not a criticism of the implementation. Static analysis reads code that is standing still. It cannot know that one of two identical-looking queries runs twice a day and the other runs 90,000 times, which is the entire difference between an irrelevance and your worst problem.
It also cannot see the plan. A query that looks perfectly ordinary in the source becomes a full table scan because a varchar column is being compared with an integer and the index is silently unusable. There is no smell in the source. There is a very clear answer in EXPLAIN, which is why Slowpoke runs one.
The same gap applies to CodeScene and Stepsize
CodeScene is the most credible tool in this category — its behavioural analysis and CodeHealth metric genuinely predict which parts of a codebase will hurt, and it is a better product than a pure smell counter. Stepsize makes recording debt painless by putting it in the editor.
Both still read the repository, and both still rely on a human deciding what matters and another human declaring it done. Slowpoke closes that loop from the other end: the measurement chooses what matters, and the measurement decides when it is finished. A mission stays open until the cost has stayed down for three windows, whether that came from a code change, an index somebody added, or simply less traffic — and the history says which, so nobody takes credit for a quiet week.
Can you run both?
Yes, and they barely touch. SonarQube guards the code on the way in; Slowpoke prices what is already out there and decides what to spend next sprint on. If you want one sentence: SonarQube tells you the code is hard to change, Slowpoke tells you which part of it is worth changing.
FAQ
Slowpoke and SonarQube, asked plainly
Is Slowpoke a technical debt tool like SonarQube?
Does Slowpoke do static analysis or security scanning?
Can Slowpoke run in CI?
How is Slowpoke's debt figure calculated?
Find out what you inherited
Fifteen minutes on one server, and the first number is yours — it costs nothing to find out.