Display Apache Server Statistics with mod_status

Learn how to enable Apache mod_status, securely configure /server-status, view worker statistics, and troubleshoot access and configuration problems on Debian and Ubuntu.

Apache's mod_status module provides a browser-accessible report about the currently running web server. The report is commonly available at /server-status and shows current and cumulative process, connection, worker, and request activity.

Use this endpoint as an operational monitoring and troubleshooting tool, not as a public application page. It can reveal request activity, worker states, server uptime, and traffic totals, so access should normally be limited to administrators or monitoring systems.

Prerequisites

Basic Apache administration on Linux.
sudo access to the server.
Familiarity with Apache VirtualHost configuration files.
Basic IPv4 and CIDR notation, such as 192.168.0.0/16.
Knowledge of Apache configuration validation and service reloads.

On Debian and Ubuntu, configuration is commonly divided among sites-available, sites-enabled, and module directories such as mods-available and mods-enabled.

What mod_status does

mod_status is the Apache module that produces server activity and status information. Apache installations often include and enable it, but this is not guaranteed. The module generates the server-status handler output, which is usually exposed through a URL such as http://server-name-or-address/server-status.

The report is a snapshot of current activity combined with counters accumulated since Apache started or was last restarted. It can help answer questions such as:

Are connections currently active?
Are most workers busy or is spare capacity available?
Are particular requests remaining active for a long time?
How many requests and bytes has this Apache instance handled?
When was the server started, and how long has it been running?

Check and enable mod_status

First, check whether the module is loaded:

sudo apache2ctl -M | grep status

A loaded module is commonly shown with an entry such as status_module. If it is not listed, enable it on Debian or Ubuntu:

sudo a2enmod status

Enabling a module changes Apache's loaded-module configuration. Apache must be reloaded or restarted before the change takes effect. Validate the complete configuration before reloading:

sudo apache2ctl configtest
sudo systemctl reload apache2

The configtest command should report Syntax OK. If it reports an error, correct that error before reloading Apache.

Configure the /server-status endpoint

A Location directive is an Apache configuration section that applies settings to a URL path. The path in <Location /server-status> corresponds to the URL suffix /server-status.

Inside the relevant VirtualHost configuration, add a location block like this:

<Location /server-status>
    SetHandler server-status
    Require ip 192.168.0.0/16
</Location>

SetHandler assigns a content handler to a location. Here it assigns Apache's server-status handler to requests for /server-status. The Apache 2.4 Require ip directive permits only the listed IP addresses or networks.

On a typical Debian or Ubuntu installation, place this block inside the applicable virtual host, for example in:

/etc/apache2/sites-available/000-default.conf

Use the virtual host that receives the hostname and port you will use for monitoring. If the server uses several sites, placing the block in the wrong virtual host can cause a 404 response or make the endpoint appear to be missing. Review Apache's default virtual host and creating a new virtual host when you need to identify the correct site configuration.

After saving the file, test and reload Apache:

sudo apache2ctl configtest
sudo systemctl reload apache2

Secure access with Require ip

The status report can disclose operational information, including current requests, worker availability, traffic volume, and server timing. Do not normally expose it to the public internet. The example above permits the private 192.168.0.0/16 network, which includes addresses from 192.168.0.0 through 192.168.255.255.

Replace that range with the smallest trusted source range that fits your environment. Common choices include:

Loopback addresses for local-only checks: 127.0.0.1 and, where applicable, ::1.
A dedicated monitoring host, such as 192.168.10.25.
A trusted administrative subnet.
A VPN address range used by administrators.

For local monitoring with one additional monitoring host, for example:

<Location /server-status>
    SetHandler server-status
    Require ip 127.0.0.1 ::1 192.168.10.25
</Location>

Apache 2.4 uses Require ip for this source-address authorization. Avoid replacing a restricted rule with unrestricted access merely to solve a 403 response.

Use case	Allowed source	Example authorization approach	Security consideration
Local-only monitoring	Loopback	`Require ip 127.0.0.1 ::1`	The endpoint is usable by local administrators or a monitoring agent, but not by remote clients.
Private LAN administration	Trusted office or server subnet	`Require ip 192.168.0.0/16`	Use a narrower subnet when possible and ensure the network is actually trusted.
Dedicated monitoring host	One monitoring server	`Require ip 192.168.10.25`	Restrict access to the monitoring system's stable source address.
VPN-based administration	VPN client range	`Require ip 10.20.0.0/24`	Ensure users cannot bypass the VPN through a public interface or proxy.

View the Apache status report

From a client in an allowed network, open the endpoint in a browser:

http://server-name-or-address/server-status

Replace server-name-or-address with the hostname or address of the Apache virtual host. If the site uses HTTPS, use the corresponding HTTPS URL and TLS port.

You can also request the report with an HTTP command-line client from an allowed host:

curl http://localhost/server-status

A client outside the permitted source network should receive an authorization failure, typically HTTP 403 Forbidden. That failure is expected when access control is working.

Understand server-status metrics

The exact layout differs somewhat between Apache versions and Multi-Processing Modules, but the report generally includes the following information.

Metric	What it reports	Operational interpretation
Active connections	Connections currently associated with Apache activity.	Shows the current connection load at the time of the report.
Busy workers	Workers currently processing requests or otherwise occupied.	A high value can indicate substantial current load.
Idle workers	Workers available to accept work.	Idle capacity is available; a sustained zero or very low value deserves investigation.
Worker scoreboard/status	A compact display of each worker's current state.	Helps identify idle, busy, waiting, reading, writing, or long-running workers.
Requests handled by a worker	The worker's request count, where provided by the report.	Shows per-worker request activity and can help reveal uneven or persistent work.
Bytes served by a worker	Data delivered by that worker.	Indicates the worker's cumulative output volume.
Total accesses	Cumulative number of requests served by Apache.	Useful for comparing traffic over the current Apache runtime.
Total bytes served	Cumulative amount of data delivered by Apache.	Helps estimate output volume since startup or restart.
Server start or restart time	When the current Apache process set began running.	Provides context for cumulative counters and recent service changes.
Uptime	Time elapsed since Apache was started or last restarted.	Use it to interpret the age of the counters and recent availability.

Interpret the worker scoreboard

The scoreboard is Apache's quick view of worker states. A worker is an Apache execution resource that can be idle, processing a request, or in another state reported by the active processing model.

Busy workers indicate workers currently handling activity.
Idle workers indicate spare capacity that can accept new work.
Long-running states can indicate slow clients, expensive application requests, blocked I/O, or a slow backend.

A brief period with few idle workers may be normal during a traffic burst. Sustained lack of idle workers, especially alongside increasing response times, suggests that you should investigate load, request duration, Apache worker limits, and application backends. Compare the report with Apache access and error logs and with monitoring from any proxy or application layer.

Verification and routine maintenance

Confirm that mod_status is loaded with apache2ctl -M.
Confirm that the Location block is inside the virtual host receiving the monitoring request.
Run sudo apache2ctl configtest.
Reload Apache with sudo systemctl reload apache2.
Request /server-status from an allowed client.
Test from a non-permitted network and confirm that it is denied.
Review the Require ip rules whenever VPNs, NAT, monitoring hosts, or network ranges change.

Keep the access rule synchronized with your network design. A reverse proxy or NAT device can change the source address Apache sees, while a proxy that publishes the endpoint must enforce equivalent restrictions. For related configuration concepts, see the apache2.conf file and Apache configuration files.

Troubleshoot common problems

404 Not Found

Possible causes include an unenabled mod_status module, a missing or inactive Location block, a block in the wrong virtual host, or a request reaching a different Apache instance.

Enable the module with sudo a2enmod status.
Check that the location assigns SetHandler server-status.
Run sudo apache2ctl configtest and reload Apache.
Verify that the requested hostname and port select the intended VirtualHost.

403 Forbidden

A 403 response usually means the client source address does not match Require ip. A reverse proxy, NAT device, or VPN may cause Apache to see a different address than the one expected.

Determine the source IP as seen by Apache.
Add only the correct trusted host or subnet.
Check whether another authorization rule adds restrictions.
Do not fix the problem by permitting unrestricted public access.

Apache will not reload

Invalid directive syntax, a misplaced location block, or an unavailable module can prevent a reload.

Run sudo apache2ctl configtest.
Read the reported configuration file and line number.
Confirm that mod_status is enabled.
Correct the error and reload only after validation succeeds.

The report shows little or no activity

The server may simply be quiet. Other possibilities are that the request reaches another Apache instance, or that traffic is handled by a proxy or backend layer.

Observe the report during a controlled request from an allowed client.
Verify the hostname, port, and selected virtual host.
Compare the result with access logs and the surrounding proxy architecture.

Status information is exposed externally

Review the authorization rule if public clients can reach the report. The rule may allow all clients, use a subnet broader than intended, or be bypassed by a reverse proxy that lacks equivalent restrictions.

Immediately limit access to localhost, a management subnet, VPN clients, or designated monitoring hosts.
Review Apache, firewall, and reverse-proxy rules together.
Retest from both permitted and non-permitted networks.

Key points

mod_status generates Apache's current and cumulative server activity report.
The usual endpoint is /server-status, configured with a Location block and SetHandler server-status.
Use Apache 2.4's Require ip to restrict access by address or subnet.
Validate configuration before every reload.
Use busy and idle worker counts, scoreboard states, counters, and uptime to guide troubleshooting, not as the sole source of performance conclusions.