Apache mod_status: Enable It, Restrict Access and Read the Scoreboard

This article is a localized edition of the Japanese original. Read the Japanese original

If you enable Apache's mod_status, the /server-status page shows you in real time "how many requests are being processed right now," "how many worker slots are free" and "which URLs are taking a long time." When your site gets slow, it is the first clue for telling whether the cause is a shortage of Apache worker slots or slowness in PHP or the database. This article explains how to enable it, why you must not expose it and how to restrict access, what to do when it collides with WordPress's .htaccess, and how to read the scoreboard.

What mod_status tells you

The server-status page mainly shows the following information.

• Server uptime, total number of accesses, requests per second and data transferred
• The number of requests being processed and the number of idle (free) workers
• The scoreboard: a list that shows, one character per worker slot, what state each slot is in right now
• Details of each request being processed: client IP, VirtualHost, requested URL, elapsed time and so on

The last detailed view appears when ExtendedStatus is On. In Apache 2.4, it is On by default when mod_status is loaded, but writing it explicitly makes the intent of the configuration clearer. Note that ExtendedStatus is not switched by a graceful restart (reload), so you need a restart when you change it.

Enabling it

Debian/Ubuntu family

In many environments, mod_status is enabled from the start. The configuration is in /etc/apache2/mods-enabled/status.conf, and by default only access from the server itself (localhost) is allowed.

sudo a2enmod status
cat /etc/apache2/mods-enabled/status.conf

RHEL/AlmaLinux family

While the module itself is often loaded by default, the /server-status URL is generally not provided by default. Create /etc/httpd/conf.d/status.conf and write the following.

ExtendedStatus On

<Location "/server-status">
    SetHandler server-status
    Require local
    # To view it from a fixed administration IP (example)
    # Require ip 203.0.113.10
</Location>

Require local allows connections only from the server itself. To view it from a fixed IP at your office, add Require ip. After making the change, check the syntax and apply it.

sudo apachectl configtest
sudo systemctl restart httpd   # apache2 on Debian/Ubuntu

Why you must not loosen access restrictions

server-status shows the URLs of requests being processed, client IP addresses and VirtualHost names. It can also reveal values in URL query strings, paths of unpublished admin screens and the existence of other sites running on the server. Avoid exposing it to the whole internet, and narrow down the sources you allow.

Pay special attention to setups where Nginx or similar on the same server sits in front of Apache as a reverse proxy. In that case, every request appears to Apache to come from 127.0.0.1, so Require local alone lets outside visitors see server-status too. Take measures such as denying external access to /server-status on the front-end proxy, or splitting it onto an administration-only port or VirtualHost on the Apache side. After setting it up, check from an outside connection that you get a 403 or 404.

When you get a 404 on a WordPress site

If WordPress is in the document root, opening /server-status may show WordPress's 404 page. WordPress's .htaccess is written to "pass requests for files and directories that do not exist to index.php," and because server-status is not an actual file either, it gets handed to WordPress. That is the cause.

Adding the following lines before # BEGIN WordPress in .htaccess excludes server-status from rewriting.

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^server-status$ - [L]
</IfModule>

The section between # BEGIN WordPress and # END WordPress is rewritten by WordPress when you save the permalink settings, so write outside it. Take a backup before editing .htaccess.

Checking from inside the server

Besides viewing it in a browser, you can log in to the server over SSH and fetch it with curl. Adding ?auto outputs it in a "field name: value" format that is easy for monitoring tools to handle.

curl -s http://127.0.0.1/server-status?auto

When viewing it in a browser, adding ?refresh=5 refreshes it automatically every 5 seconds, which makes it easier to follow changes while the server is under load.

Monitoring tools such as Zabbix, Prometheus (apache_exporter) and Netdata also have mechanisms that read mod_status's ?auto output and graph Apache's state. Template and setting names change with the tool's version, so check each tool's documentation (as of October 2026).

How to read the scoreboard

The scoreboard shows the state with one character per worker slot. These are the characters you will often see.

• _: waiting for a connection (a free worker slot)
• W: sending a response. This state also appears while waiting for PHP to process
• R: reading a request
• K: waiting for the next request in KeepAlive
• C: closing the connection
• G: after a graceful restart, waiting for in-flight requests to finish
• .: a slot whose process has not started yet

Almost no free slots (_)

This means you are short of worker slots. Check whether the error log contains a message saying the MaxRequestWorkers limit has been reached.

sudo grep -i "MaxRequestWorkers" /var/log/apache2/error.log   # /var/log/httpd/error_log on RHEL family

If you have reached the limit, review MaxRequestWorkers within the range your memory allows. Before you add slots, though, first check whether each request has become slower to process.

Many W entries, with the same URL taking a long time

In the ExtendedStatus detail view, check the URLs of requests with long elapsed times. On WordPress, the cause can be a specific page, an admin screen operation, or a large volume of access to xmlrpc.php or wp-login.php. If you use PHP-FPM, Apache's W also includes waiting for FPM to process, so checking the PHP-FPM status page and slow log as well helps you narrow down the cause.

Most slots are K (with prefork)

With the prefork MPM, a slot is occupied even while it waits in KeepAlive. If KeepAliveTimeout is too long, slots fill up with connections that are not actually processing anything. Shorten KeepAliveTimeout, or consider switching to the event MPM.

With the event MPM

With the event MPM, a table summarizing connection states is shown in addition to the scoreboard. Connections in KeepAlive do not occupy a processing thread, so be careful not to judge the number of K by the same standard as with prefork.

Summary

• Enabling mod_status lets you check the number of requests in progress, the number of free workers and the scoreboard at /server-status
• Because URLs and client IPs are shown, narrow the allowed sources with Require local or Require ip. With a reverse proxy in front, Require local alone is not enough
• If you get a WordPress 404, exclude server-status from rewriting before the WordPress block in .htaccess
• ?auto gives output for monitoring tools, and ?refresh=seconds gives automatic refresh
• If there are no free slots, suspect a shortage of workers; if W lasts long, suspect PHP or the database; if there are many K on prefork, suspect KeepAliveTimeout

• Tuning the number of Apache processes and threads
• Optimizing connections with Apache KeepAlive settings

Questions about WordPress? The publisher of this site is based in Japan and replies in Japanese. Contact (Japanese)