Web & Application Servers
    Updated May 2026
    PHP-FPM logo

    PHP-FPM Monitoring

    Monitor PHP-FPM accepted conn, listen queue depth, active vs idle processes, slow requests, and `max_children_reached` per pool in real time — agent-based via the native `/fpm/status` endpoint.

    Why monitor PHP-FPM?

    PHP-FPM sits between Nginx (or Apache) and your application code — every PHP request flows through it. When pools saturate, workers leak, or queries slow down, every page on the site feels it. Per-pool monitoring is the most useful signal between user-reported slowness and root cause.

    Auto-discovery via Xitogent — every pool on the host detected automatically
    Per-pool process-pool tracking: active, idle, total, max active processes
    `listen queue` and `max listen queue` depth for backpressure detection
    `max children reached` counter — the canonical pool-exhaustion signal
    Slow request count and slowlog awareness (`request_slowlog_timeout`)
    Per-pool memory and request duration tracking
    Process-manager mode awareness (`static` / `dynamic` / `ondemand`)
    Multi-pool, multi-PHP-version support on the same host
    Customizable alert thresholds per pool
    1-minute metric collection intervals out of the box
    What is PHP-FPM monitoring?

    PHP-FPM monitoring, explained

    PHP-FPM monitoring catches pool exhaustion, slow queries, and worker leaks before they slow every PHP request on the server. For WordPress, Laravel, Magento, and any Nginx + PHP-FPM stack, per-pool visibility is the single most useful signal between user-reported slowness and root cause. Xitoring auto-discovers every pool on the host, polls the native /fpm/status endpoint on a 1-minute interval, and routes alerts to your existing on-call rotation.

    Metrics

    What we monitor

    Active Processes

    Workers currently processing PHP requests, per pool. The first signal for pool saturation.

    Idle Processes

    Workers waiting for requests. With `pm.dynamic`, watch this against `pm.min_spare_servers` and `pm.max_spare_servers`.

    Total Processes

    Active + idle workers per pool. Compare against `pm.max_children` to know your headroom.

    Max Active Processes

    Peak observed concurrent requests per pool. The right input for sizing `pm.max_children` correctly.

    Listen Queue

    Requests waiting for a free worker (kernel-level backlog). Sustained non-zero values mean every PHP request is waiting on the pool.

    Max Listen Queue

    Peak observed listen queue depth. If it ever approaches `listen.backlog`, kernel-level connection drops are imminent.

    Max Children Reached

    Count of times the pool hit `pm.max_children` since the last reload. Any non-zero value is a hard signal to raise the limit or add a pool.

    Slow Requests

    Requests exceeding `request_slowlog_timeout`, written to `slowlog` with a backtrace. Trending up means application code or database queries are degrading.

    Accepted Conn

    Total connections accepted by the pool since start. Combined with `start since` (uptime) gives a clean requests-per-pool rate.

    Memory per Process

    Average resident memory per worker. Steady growth between recycles points at a leak — tune `pm.max_requests` to recycle more aggressively.

    Request Duration

    Average request processing time per pool, from `?full` status output. Track p95 to catch tail latency invisible to averages.

    Triggers & Alerts

    Configurable alert triggers

    Set up custom triggers in your dashboard to get notified the moment PHP-FPM metrics cross your defined thresholds.

    PHP-FPM monitoring trigger configuration dashboard

    Slow Requests

    warning

    Fires when slow request count exceeds threshold.

    Listen Queue

    critical

    Triggers when requests are queuing, indicating insufficient workers.

    Max Children

    critical

    Alerts when process limit is reached repeatedly.

    Memory Usage

    warning

    Fires on high per-process memory usage.

    Active Processes

    warning

    Triggers when all workers are busy.

    01

    Importance of PHP-FPM Monitoring

    PHP powers 77% of websites. Without monitoring, slow scripts, memory leaks, and worker exhaustion can bring applications to a halt.

    • Detect slow PHP scripts before they impact users
    • Right-size process pools based on real data
    • Prevent memory exhaustion from leaky scripts
    • Monitor listen queue to avoid request drops
    PHP-FPM monitoring dashboard
    PHP performance analytics
    02

    Why Choose Xitoring

    Seamless PHP-FPM monitoring with zero-config setup and multi-pool support.

    • One-command install
    • Multi-pool monitoring support
    • Unified dashboard
    • Multi-channel alerting
    • Historical data retention
    Xitoring PHP overview
    Alert configuration
    Use cases

    Common PHP-FPM monitoring scenarios

    Where PHP-FPM typically runs today — and what could go wrong if no one's watching.

    WordPress, Laravel, and other PHP sites

    Most PHP sites get slow for the same reason: there aren't enough workers free to handle incoming visitors fast enough. We catch the bottleneck the moment it begins so the team can fix it before search rankings or conversions take a hit.

    PHP apps running in containers

    When the same app runs in many containers, some can quietly handle much more traffic than others. We surface the uneven load so the team can rebalance before some visitors get a slower experience than others.

    Many websites on shared hosting

    On shared hosting, one noisy customer site can quietly consume the resources every other site needs. We show which site is causing the problem so the team can address the cause instead of restarting blindly.

    Before you start

    Prerequisites for PHP-FPM

    Make sure you've got these in place — most installs are a 60-second job once they are.

    • PHP-FPM with pm.status_path = /fpm/status (and optionally ping.path = /fpm/ping) set per pool
    • The status URL accessible from localhost (via Nginx fastcgi_pass or Apache equivalent)
    • Read access to PHP-FPM logs and pool config
    Setup Guide

    Get started in minutes

    1

    Install Xitogent on your web server

    Install the lightweight Xitogent monitoring agent on the host running PHP-FPM.

    curl -s https://xitoring.com/install.sh | sudo bash -s -- --key=YOUR_API_KEY
    2

    Enable the PHP-FPM status page

    Set `pm.status_path = /fpm/status` and `ping.path = /fpm/ping` in your pool config (typically `/etc/php/X.Y/fpm/pool.d/www.conf`). Add a fastcgi_pass location block in Nginx (or equivalent for Apache) to expose the path to localhost, then reload PHP-FPM and verify the URL responds.

    # In your PHP-FPM pool config (e.g. /etc/php/8.x/fpm/pool.d/www.conf) pm.status_path = /fpm/status ping.path = /fpm/ping # Then in Nginx, expose them to localhost: location ~ ^/fpm/(status|ping)$ { allow 127.0.0.1; deny all; fastcgi_pass unix:/var/run/php-fpm/www.sock; include fastcgi_params; }
    3

    Enable the PHP-FPM integration

    Use the Xitoring dashboard or CLI to enable the PHP-FPM integration. Xitogent auto-detects every FPM pool on the host and tracks them independently.

    sudo xitogent integrate
    4

    Configure alert thresholds (optional)

    Set custom thresholds for Slow Requests, Listen Queue, or Max Children Reached to catch performance regressions and pool exhaustion before users feel them.

    5

    Verify it's working

    Run this command on the server to confirm Xitogent picked up the integration. Fresh metrics will start streaming to your dashboard within ~30 seconds.

    sudo xitogent status

    Frequently asked questions

    What is PHP-FPM monitoring?
    PHP-FPM monitoring is the continuous collection of per-pool worker-process metrics — `accepted conn`, `listen queue`, `idle/active/total processes`, `max active processes`, `max children reached`, `slow requests`, plus the process-manager mode and per-pool memory — combined with alerting when those metrics breach thresholds. Because PHP-FPM sits between your web server and your application code, it's the single most important PHP-side signal for application latency.
    How do I enable the PHP-FPM status page?
    Set `pm.status_path = /fpm/status` and `ping.path = /fpm/ping` in the pool config (typically `/etc/php/X.Y/fpm/pool.d/www.conf`). Reload PHP-FPM (`systemctl reload phpX.Y-fpm`). Then expose the path through Nginx with: `location ~ ^/(fpm/status|fpm/ping)$ { fastcgi_pass unix:/var/run/php/php-fpm.sock; include fastcgi_params; allow 127.0.0.1; deny all; }`. Reload Nginx and verify with `curl http://127.0.0.1/fpm/status`.
    What is the difference between pm.dynamic, pm.static, and pm.ondemand?
    `pm = static` keeps a fixed number of workers running (`pm.max_children`) — best for predictable high traffic, lowest latency, highest baseline memory. `pm = dynamic` (the default) scales between `pm.min_spare_servers` and `pm.max_spare_servers` based on load — best general-purpose mode. `pm = ondemand` spawns workers only when needed and kills them after `pm.process_idle_timeout` — lowest memory, slight cold-start latency, best for low-traffic shared hosting.
    How do I detect PHP-FPM slow requests?
    Set `request_slowlog_timeout = 5s` (or your tolerance) and `slowlog = /var/log/php-fpm/slow.log` in the pool config. Any request exceeding the timeout gets a full PHP backtrace dumped to the slowlog, and the `slow requests` counter on the status page increments. Xitogent surfaces both the count (for trending) and parses the slowlog for top offenders by call site.
    What does max_children_reached mean and why does it matter?
    `max_children_reached` increments every time PHP-FPM tried to spawn a new worker but was already at `pm.max_children`. New requests then queue in the kernel listen backlog, adding latency to every PHP request. Any non-zero rate is a hard signal: either raise `pm.max_children` (if you have RAM headroom — calculate `max_children × memory_per_process` first), add a second pool, or fix the code paths blocking workers.
    How do I monitor multiple PHP-FPM pools on one server?
    Xitogent auto-discovers every pool by scanning `/etc/php/*/fpm/pool.d/` and probing the configured `pm.status_path` for each. Per-pool metrics, alerts, and history are tracked independently in the dashboard — useful for cPanel multi-site setups, multi-PHP-version hosts (8.2 + 8.3 + 8.4 in parallel), and Laravel Octane / Symfony deployments running separate pools per worker class.
    How do I troubleshoot a growing listen queue?
    A growing `listen queue` means PHP requests arrive faster than workers can process them. Three knobs: (1) raise `pm.max_children` if RAM allows, (2) reduce per-request work via OPcache + query optimization + slowlog analysis, (3) split into multiple pools to isolate slow endpoints. If `listen queue` approaches `listen.backlog`, kernel-level connection drops are imminent — bump `listen.backlog` and tune `net.core.somaxconn` on Linux.
    What PHP versions are still receiving security updates?
    As of 2026: PHP 8.4 (current LTS, supported until Dec 2028), PHP 8.3 (supported until Dec 2027), PHP 8.2 (security only, EOL Dec 2026). PHP 8.1 reached EOL Dec 2025 — extended life is available commercially via HeroDevs NES or TuxCare. The integration works with all of them; pool config syntax is stable across the 8.x line.
    Will the status page affect PHP performance?
    No measurable impact. The status endpoint is a lightweight C-level handler that doesn't go through the request-execution pipeline — it just serializes the in-memory pool state. Polling it every 60 seconds adds zero contention to real PHP request processing.

    Start monitoring PHP-FPM today

    Set up in under 60 seconds. No credit card required. Full metrics from day one.

    Start Free Trial

    Keep exploring

    Related Integrations