VMware ESXi and vSphere Cluster Management

Display Apache Server Statistics with mod_status

Learn how to enable, secure, validate, and interpret Apache HTTP Server runtime statistics with the mod_status server-status endpoint.

Apache HTTP Server can expose a live runtime report through the mod_status module. The report helps administrators monitor worker activity, investigate slow or overloaded servers, check capacity, and confirm that Apache is handling requests as expected.

This guide covers Debian- and Ubuntu-based systems, where Apache modules are commonly managed with a2enmod. The same Apache directives can also be used on other platforms, although file locations and service commands may differ.

What Apache server statistics provide

Apache HTTP Server is the web server software being monitored. Its mod_status module generates a live report about the currently running server. The conventional URL for this report is /server-status.

Unlike access logs, which record completed requests, the status report shows current worker activity and cumulative counters. It is useful for:

Operational monitoring of active connections and requests.
Capacity checks, including whether workers are busy or waiting for work.
Troubleshooting slow responses, worker saturation, and overloaded servers.
Confirming that Apache workers are accepting and serving requests.
Comparing traffic and worker behavior before, during, and after an incident.

How mod_status works

mod_status is the Apache module responsible for producing the runtime report. The server-status value is the content handler that generates that report. A Location directive is the Apache configuration section used to apply settings to a URL path, and SetHandler assigns a handler to that path.

The endpoint needs both of these pieces:

The mod_status module must be loaded.
A Location block must map /server-status to the server-status handler.

The module may already be enabled, especially on a preconfigured Apache installation. On Debian- or Ubuntu-style systems, verify enabled modules with:

sudo apache2ctl -M | grep status

If the command shows a status module, it is loaded. If it produces no result, enable the module with:

sudo a2enmod status

Enabling a module changes Apache's enabled-module configuration, but you should still validate the complete configuration and reload Apache after making changes.

Configure the /server-status endpoint

Add a Location block to an appropriate Apache configuration file. It can be placed in a global configuration file or inside the relevant VirtualHost. A VirtualHost is an Apache configuration container for a site or hostname.

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

This example serves the report at /server-status and permits clients from the private 192.168.0.0/16 network. CIDR notation identifies an IP network and its prefix length; /16 covers addresses from 192.168.0.0 through 192.168.255.255.

When the block is inside a virtual host, the endpoint is available through hostnames that select that virtual host. For example, a request to http://server-hostname-or-address/server-status may reach a different virtual host depending on the requested hostname, address, port, and Apache's virtual-host order. Put the block in the site configuration that should answer the monitoring request, and test using that site's actual hostname.

Restrict access securely

Apache 2.4 uses the Require directive for authorization. Prefer the narrowest rule that meets the monitoring requirement.

Use case	Authorization approach	Security considerations
Localhost-only monitoring	`Require local`	Only requests originating from the same server are allowed. This is a strong default for a local monitoring agent.
Single monitoring host	`Require ip 192.168.10.25`	Limits access to one trusted address. Confirm that NAT or a proxy does not change the source address seen by Apache.
Trusted private subnet	`Require ip 192.168.0.0/16`	Convenient for an internal administration network, but broader than allowing one host. Protect the subnet itself.
Public access	`Require all granted`	Allows every client and can disclose operational information. Avoid this unless there is a compelling reason and strong network controls.

Allow only local monitoring

For an agent running on the Apache machine, use:

<Location /server-status>
    SetHandler server-status
    Require local
</Location>

The local agent can query the endpoint without publishing it to the network:

curl http://127.0.0.1/server-status

Use network-level protection as well

Authorization rules in Apache should be combined with suitable infrastructure controls. A firewall can block unwanted traffic before it reaches Apache. A VPN or private network can keep monitoring traffic off the public Internet. A reverse proxy can provide an additional access-control boundary when the endpoint must be reached through a controlled internal service.

Do not assume that a private IP rule alone is sufficient if a load balancer, NAT gateway, or reverse proxy changes the source address. Verify which client address Apache actually receives.

Apply and validate the configuration

Always test Apache syntax before reloading or restarting the service:

sudo apache2ctl configtest

A successful test normally reports Syntax OK. If validation succeeds, reload Apache so it reads the module and endpoint changes:

sudo systemctl reload apache2

Open the endpoint through the relevant hostname:

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

Or validate locally with:

curl http://127.0.0.1/server-status

A successful response should contain an Apache status report rather than an ordinary site page. A 403 Forbidden response from an unapproved address is expected when access restrictions are working correctly.

Read the status report

The exact layout depends on Apache's multiprocessing module and version, but the report commonly includes active request information, worker counts, a scoreboard, per-worker details, cumulative counters, and timing information.

A worker is an Apache process or thread responsible for accepting or serving requests, depending on the configured multiprocessing module. The scoreboard is the display of the current state of those workers.

Metric or report section	What it represents	What administrators can infer
Active requests or connections	Requests or connections currently being handled by Apache.	High values may indicate a traffic spike, slow clients, or requests waiting on application and upstream services.
Busy workers	Workers currently handling requests or other active work.	If nearly all workers are busy for a sustained period, available capacity may be low.
Idle workers	Workers waiting for new work.	A healthy reserve of idle workers usually indicates that Apache can accept additional requests, although application and network limits also matter.
Worker scoreboard states	One-character or state indicators showing what each worker is doing, such as waiting, reading, sending, or finishing.	A large concentration in one active state can point toward slow clients, long-running responses, or backend delays. Interpret states using the Apache version and configured worker model.
Requests handled per worker	The number of requests served by each worker during its lifetime or since the relevant server start.	Helps show distribution of work and whether some workers are handling unusually many requests.
Bytes served per worker	The amount of response data served by each worker.	Useful for identifying workers serving large responses or traffic patterns that differ from the average.
Total accesses	The cumulative number of accesses handled by the server.	Shows overall request volume since the server started or the counter was reset.
Total bytes served	The cumulative response data served by Apache.	Helps estimate traffic volume and compare request counts with average response size.
Server start time	The time Apache was started or most recently restarted.	Useful for correlating counter resets and configuration changes with operational events.
Uptime	Elapsed time since the last Apache start or restart.	Provides the time period over which cumulative counters and worker activity have accumulated.

Use the report during an incident

Check active connections and requests for an unusual increase.
Compare busy workers with idle workers. Nearly no idle workers suggests pressure on Apache capacity.
Review scoreboard states to see whether workers are serving responses, reading requests, waiting, or finishing.
Compare per-worker request and byte counts for unusual request or response behavior.
Use uptime and cumulative totals to distinguish a recent restart from a sustained traffic pattern.
Check application, database, upstream, and reverse-proxy health before increasing Apache capacity. Worker saturation can be a symptom of a slow dependency rather than the root cause.

Optional detailed statistics with ExtendedStatus

ExtendedStatus enables additional request and worker detail in the status output. If detailed per-worker information is required, add this setting in an appropriate Apache configuration context:

ExtendedStatus On

More detail can improve diagnosis and monitoring, but it also has operational and information-disclosure implications. Keep detailed status data restricted to administrators and trusted monitoring systems. If the extra information is not needed, leave the setting disabled or remove it, and keep the endpoint protected with narrow Require rules.

Troubleshooting common problems

404 Not Found

Common causes include an unloaded mod_status module, a missing Location block, a block placed in the wrong virtual host, or a request reaching a different site configuration. Enable the module, confirm that the block contains SetHandler server-status, verify virtual-host selection, and reload Apache.

403 Forbidden

The requesting client may not match the Require rule. A proxy, NAT gateway, or load balancer may also cause Apache to see a different source address than expected. Confirm the address Apache receives, then adjust the allowed IP or subnet only if the source is trusted. Testing with Require local can help separate endpoint problems from network authorization problems.

Apache will not reload

A syntax error, invalid directive, or unsupported configuration context may prevent a reload. Run:

sudo apache2ctl configtest

Review the reported file and line number. Ensure the Location block is in a supported Apache configuration context, correct the error, and run the test again before reloading.

Unexpected worker saturation

Traffic may exceed normal capacity, an application or backend dependency may be slow, or Apache's configured worker capacity may be too low. Compare busy and idle workers over time rather than relying on one snapshot. Inspect application and upstream service health, then review the configured multiprocessing module and capacity settings after identifying the bottleneck.

The report exposes too much information

Disable ExtendedStatus if detailed output is unnecessary. Narrow the Require rule, restrict access with a firewall or VPN, and ensure that public clients cannot reach the endpoint.

Operational checklist

Confirm that mod_status is loaded.
Map /server-status to the server-status handler.
Place the configuration in the virtual host or global context that should serve the endpoint.
Allow only localhost, a monitoring host, or a trusted private subnet.
Avoid Require all granted for normal deployments.
Run sudo apache2ctl configtest before applying changes.
Reload Apache with sudo systemctl reload apache2.
Verify the response with the appropriate hostname or local curl request.
Interpret worker saturation alongside application, backend, and network measurements.

For related Apache configuration concepts, see Apache server statistics with mod_status.