An Xdebug alternative?
Only for one of its jobs.

Xdebug does several things, and most of them have no good replacement. If you want to step through a request line by line, stop reading: keep Xdebug, we do not do that and we are not going to pretend otherwise. There is exactly one job where Xdebug is the wrong tool, and it is the one that sent you here — finding out why something is slow in production.

Keep Xdebug for these

• Step debugging (xdebug.mode=debug) — breakpoints, watches, stepping through a request in your editor. Nothing else in PHP does this as well.
• Local profiling (xdebug.mode=profile) — a full call graph of a request you can reproduce on your own machine, opened in KCachegrind or PhpStorm.
• Code coverage (xdebug.mode=coverage) for PHPUnit.
• Development helpers — the overloaded var_dump() alone is worth the install.

Modes and their names as the Xdebug documentation lists them, read on 22 September 2026: off, develop, debug, trace, coverage, gcstats, profile.

Where it stops: production

You cannot turn it on for one request

xdebug.mode is read from php.ini at startup — it is not a per-request switch. So "just enable the profiler for the slow checkout" means enabling it for every request on that worker, then restarting PHP to turn it off again.

The cost is not documented, so we measured it

Xdebug's own documentation says only that off gives "close to 0 overhead". It puts no number on the other modes. We ran xdebug.mode=profile against a real WordPress page and published the method with the raw figures:

• 40 ms became 1012 ms — 25× slower on the same page, five interleaved rounds, Xdebug spread 999–1034 ms against a baseline spread of 39.5–40.8 ms.
• Sixty requests wrote 1.2 GB of cachegrind files — roughly 40 MB per profiled request. On a busy site that fills a disk before you find the request you were looking for.

And the request already happened

The profiler records what you profile from now on. The checkout that took nine seconds at 3 a.m. is gone, and you cannot reproduce it — that is usually the whole problem.

What PHPRay does instead

It records every request, all the time, and keeps it: wall time, CPU, memory, SQL fingerprints with the literals stripped, outbound HTTP, PHP errors, N+1 patterns. You open yesterday's slow request instead of trying to recreate it today.

That is only honest if the recording is cheap, so here is our own number on the same WordPress page: 40.7 ms against a 40.2 ms baseline — inside the noise. Per-function attribution, which is the part that resembles what Xdebug's profiler gives you, is sampled and costs about 4% on that page; on a 48 ms micro-benchmark it cost 27%, and we published that row too.

Side by side

The short version

• Debugging logic, locally, line by line → Xdebug.
• Full call graph of a request you can reproduce → Xdebug.
• "It is slow in production and I cannot reproduce it" → PHPRay.
• Both, on the same machine, is fine. They do not collide: keep xdebug.mode=off in production, where it costs close to nothing, and let PHPRay do the recording.