Slowpoke vs Sentry
Sentry is the best error tracker there is and most teams should have one. It also has performance features, and a self-hosted option that is a small distributed system. Slowpoke does one narrow thing instead, and installs like a single binary.
The short answer
Which one you should pick
These solve different problems and the pairing is natural: Sentry catches what threw an exception, Slowpoke prices what quietly wastes everyone's time.
Choose Sentry if
You need to know what broke
- You need exceptions, stack traces, release health and issue triage — the thing Sentry is famous for.
- You want breadcrumbs and the user session that led to a crash.
- You already run Sentry and the performance tab is enough for your slow-query needs.
- You want source maps, mobile crash reporting and a mature issue workflow.
Choose Slowpoke if
You need to know what is slow and what it costs
- Nothing is throwing. Everything just takes too long, and nobody can say which thing to fix.
- You want real EXPLAIN plans with the index to add, not a slow transaction list.
- You want to self-host without running Kafka, ClickHouse and Postgres to do it.
- You need the database server, the machines and the queues in the same picture as the application.
- You need a number for the people who fund the work.
Side by side
Slowpoke and Sentry, line by line
Written to be fair, including where Sentry 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 | Sentry |
|---|---|---|
| What it answers | What is slow, what it costs, what to fix first | What broke, where, and for whom |
| Self-hosting | One Go binary plus SQLite or PostgreSQL | A fleet: Relay, Kafka, ClickHouse and Postgres |
| Server image size | 21 MB, distroless, non-root | A multi-container stack |
| Price | €0, self-hosted, no meter | Generous free tier, then per-event volume; self-hosting is free but not small |
| Errors and exceptions | Not its job | The whole point, and very good at it |
| Slowness as a priced list | Seconds of waiting per day | Slow transactions, by duration |
| Query plans with a fix | Real EXPLAIN, twelve named diagnoses | Query spans, no plan |
| The machine and the database server | CPU, iowait, swap, OOM, disk, Redis, pools | Application only |
| Maps what you inherited | One command reads each machine | You instrument the app |
| Work that verifies itself | Missions closed by measurement | Issue states, set by hand |
| Session replay | Never | Yes |
| Release health and regressions | Deploy verdicts and bosses from regressions | Release health, adoption, crash-free rate |
Self-hosting is where these two are least alike
Sentry's self-hosted distribution is honest about what it is: a fleet of services including Relay, Kafka, ClickHouse and Postgres. It works, and plenty of companies run it, but it is a system you operate rather than a program you install — and the resources it wants are not trivial for a team that is currently trying to find out why the checkout is slow.
Slowpoke is a 21 MB distroless server image running as a non-root user, plus a 15 MB agent per machine, and SQLite is a supported database if you would rather not run PostgreSQL. That is the whole thing. It is a deliberate constraint: the buyer this is built for is one person in their first month at a company, and they do not have a platform team to lean on.
An exception is loud. Slowness is not.
Errors announce themselves: something threw, somebody noticed, Sentry caught it. That is a solvable problem and Sentry solved it well.
Performance debt is the opposite. Nothing fails. A query takes 40 ms instead of 2 ms, runs 90,000 times a day, and quietly costs an hour of your customers' collective time every single day. It appears in no error report and in no p95 alert, because 40 ms is a perfectly respectable number. Slowpoke exists to make that visible: it multiplies duration by frequency, prices everything in the same unit, and sorts.
Where the slow thing actually lives
Sentry sees your application, because your application is where the SDK is. A great deal of slowness is not in your application. It is a PHP-FPM pool with too few workers, a database server at 17% iowait, a Redis with an eviction problem, a nightly command that overlaps the backup, or a queue worker nobody has looked at since it was written.
Slowpoke's agent reads the machine as well as the app: access logs, the php-fpm slow log, MySQL and PostgreSQL statistics with real query plans, Redis, /proc, queued jobs and scheduled commands — and it traces each network connection back to the process that opened it, so the map shows the service that answers, not a port number.
Can you run both?
Yes, and this is probably the best pairing on this whole list. Sentry tells you what threw; Slowpoke tells you what is quietly expensive. There is no overlap to manage, no double counting, and Slowpoke's agent never sits in your request path, so it cannot interfere with the Sentry SDK.
FAQ
Slowpoke and Sentry, asked plainly
Does Slowpoke do error tracking?
Is Slowpoke easier to self-host than Sentry?
Sentry has performance monitoring. Why would I add Slowpoke?
Can I run both without double counting?
Find out what you inherited
Fifteen minutes on one server, and the first number is yours — it costs nothing to find out.