Continuous profiling for PHP
exists. Read the requirements first.

If you came here expecting "nobody does continuous profiling for PHP", that is not true and we are not going to pretend it is. Two serious options exist. What they have in common is a requirement most PHP is not deployed under: a host you fully control.

Requirements below were read from the vendors' own documentation on 22 September 2026, with the source named in each case. If something has changed, tell us and we will correct it.

What is actually available

Datadog Continuous Profiler

Supports PHP properly: PHP 7.1+ on 64-bit Linux, glibc 2.17+ or Alpine 3.13+. It needs two things installed: the Datadog Agent (v6+, a daemon on the host) and the dd-trace-php extension, put in place by an installer script that edits your PHP INI. Not supported on serverless platforms. Read from Datadog’s PHP profiler page on 22 September 2026; that URL now redirects to the profiler setup index, where PHP is one of the listed languages.

If you run your own servers and already pay Datadog, this is the mature answer and we will not talk you out of it.

Grafana Pyroscope

Has SDKs for Go, Java, Python, .NET, Ruby, Node.js and Rust. PHP is reached only through eBPF auto-instrumentation with Grafana Alloy — there is no PHP SDK. eBPF means a privileged agent and a kernel you control, which rules out shared hosting and most managed platforms. You get CPU stacks; you do not get the SQL statement, the outbound HTTP call or the PHP error that belonged to one slow request.

Where that leaves most PHP

A large share of PHP runs where neither is installable: shared hosting, a client's cPanel or DirectAdmin account, a managed platform, a small VPS where a per-host APM price is out of proportion to the app. That is the gap PHPRay was built for — and it is worth saying plainly what we do and do not do.

We are not a continuous profiler. Here is what we are

Continuous profiling, in the Pyroscope sense, samples CPU stacks all the time and gives you flame graphs over a time range. We do not do that. What we do:

• Always-on request recording. Every request, not a sample: wall time, CPU, memory, every SQL query as a fingerprint with the literals stripped, outbound HTTP, PHP errors and N+1 patterns. Kept, so you open yesterday's slow request.
• Per-function attribution on a sample (3% by default), which is the part that resembles a profiler: time attributed to plugins, themes and vendor packages.
• Profiling one URL on demand for a few minutes, from the console or an agent, without SSH and without restarting PHP.

If what you need is a CPU flame graph of your whole fleet over the last week, take Pyroscope or Datadog. If what you need is "which request was slow last night and why", that is the thing we record and they sample.

What it costs to leave on

Any always-on tool is only interesting if the cost is small enough to ignore. Ours is measured on a real WordPress page rendering in about 48 ms, with the method published:

The 4% row is the inconvenient one and we publish it anyway: per-function attribution is on or off per worker, so sampling does not make it cheaper. Raw numbers and method in what always-on tracing costs.

Side by side