Slowpoke vs Blackfire
Blackfire is a profiler, not a monitor, and the distinction matters more than the feature lists suggest. It answers "where does the time go inside this request" with a call graph nobody else matches. It does not answer "which of my two hundred endpoints is costing me the most" — and Slowpoke does not answer the first question at all.
The short answer
Which one you should pick
This is the least competitive pairing on the site. These are two halves of the same workflow, and the honest recommendation for a PHP team is usually both.
Choose Blackfire if
You need to know what happens inside one request
- You have a slow endpoint already identified and you need the call graph: which function, how many calls, how much memory.
- You want deterministic profiling with assertions you can run in CI to stop a regression before it ships.
- You are comparing two implementations and want a before-and-after profile of the same code path.
- You need CPU, memory, I/O and network broken down inside PHP or Python — Slowpoke does none of this.
Choose Slowpoke if
You do not yet know which request to profile
- You have two hundred endpoints and a week, and you need them ordered by what they actually cost.
- You want the database side: the plan, the index to add, and how often the statement really runs.
- You want the machine, the pools, the queues and the scheduled commands in the same picture.
- You want a number for the people who approve the sprint.
- You want it free, self-hosted and continuous, not a profile you remember to take.
Side by side
Slowpoke and Blackfire, line by line
Written to be fair, including where Blackfire 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 | Blackfire |
|---|---|---|
| What it is | Continuous production monitoring and a priced backlog | A deterministic profiler |
| What it answers | Which thing costs the most, and what to change | Where the time goes inside one request |
| Granularity | Endpoint, query, job, command | Function, call by call |
| Price model | €0, self-hosted | Traces quota, from one million traces a month |
| Where your data lives | Your machines, always | Blackfire's cloud |
| Always on in production | Yes, read-only, capped at one core and 64 MB | Profiling is sampled or triggered, not continuous |
| Cost in seconds of waiting per day | Yes, everything on one scale | — |
| Query plans with a fix | Real EXPLAIN, twelve named diagnoses | Shows the query, not the plan |
| Function-level CPU and memory | No | Yes, in detail |
| Performance assertions in CI | No | Yes |
| Languages | Any through logs and OTLP; Laravel package for origins | PHP and Python |
| The machine and the database server | CPU, iowait, swap, OOM, disk, Redis, PHP-FPM pools | — |
| Work that verifies itself | Missions closed by measurement | — |
A profiler answers a question you have to already be asking
To profile something you must first decide what to profile. That decision is the expensive part, and it is usually made badly: somebody complains about a page, an engineer profiles that page, and the three endpoints quietly costing ten times more are never looked at because nobody complained about them.
Slowpoke exists to make that decision correctly. It watches everything continuously, prices each endpoint, query, queued job and scheduled command in seconds of waiting per day — duration multiplied by how often the thing actually happens — deduplicates, and sorts. The top of that list is where a profiler earns its money.
What Slowpoke deliberately does not do
There is no function-level profiling in Slowpoke, no call graph, no per-call memory attribution, and there will not be. That work requires being inside the process with an extension, sampling or instrumenting every call, and it is in direct conflict with the rule the whole project is built on: never make the monitored application slower. The agent is capped at one CPU core and 64 MB, is read-only, and never sits in the request path.
The closest Slowpoke gets is the php-fpm slow log, which tells you where PHP workers stall down to the file and the line, with no profiler in production. That is a coarse answer. When you need the fine one, you want Blackfire.
The two halves, in order
In practice the loop looks like this. Slowpoke says POST /checkout costs 168 seconds of waiting a day and the php-fpm slow log keeps stalling in PaymentGateway.php:118. You profile that one endpoint with Blackfire and find the function actually burning the time. You fix it, ship it, and Slowpoke gives the deploy a verdict against the hour before it — then keeps the mission open until the cost has stayed down for three windows.
Neither tool does the other's job, and the combination costs you only what Blackfire costs, because Slowpoke is free.
Can you run both?
Yes, and this is the pairing we would actively recommend to a PHP team. Slowpoke chooses the target and proves the fix held; Blackfire explains what is happening inside it. They do not overlap, they do not conflict, and Slowpoke's agent is not in your request path so it cannot distort a profile.
FAQ
Slowpoke and Blackfire, asked plainly
Is Slowpoke a profiler?
Can I use Slowpoke instead of Blackfire?
Does Slowpoke slow down PHP?
Does Slowpoke work with Symfony, which Blackfire came from?
Find out what you inherited
Fifteen minutes on one server, and the first number is yours — it costs nothing to find out.