VMware ESXi and vSphere Cluster Management

Apache Server Status: Monitoring with mod_status

Learn how to enable, secure, read, and monitor Apache server-status with mod_status, ExtendedStatus, scoreboard states, MPM limits, and troubleshooting methods.

Apache's server-status endpoint provides a live operational view of an Apache HTTP Server. It shows activity such as uptime, request rate, traffic, busy workers, idle workers, and a compact worker-state display called the scoreboard. The endpoint is supplied by the mod_status module.

This page is intended for system administrators, hosting operators, and developers troubleshooting Apache capacity or request handling. It is not a replacement for access logs, error logs, application performance monitoring, or system metrics.

What the Apache server-status page is for

The status page is a point-in-time operational monitor. It helps answer questions such as:

How long has Apache been running, and when was it last restarted?
How many requests and bytes is Apache handling?
Are workers available, or are most of them busy?
Are workers spending an unusual amount of time reading requests, sending responses, or waiting for connections?
Is the server approaching a configured concurrency limit?

Use it during performance investigations, capacity planning, request-backlog analysis, and worker-saturation diagnosis. Access logs describe completed requests and their properties over time; application analytics describe users and business events; server-status describes Apache's current processing state. These sources should be correlated rather than treated as interchangeable.

Security warning: A status page can reveal client addresses, request paths, server details, traffic patterns, and operational capacity. Do not publish /server-status to the public internet.

How mod_status supplies the endpoint

mod_status is the Apache module that exposes runtime server status information. The commonly used URL path is /server-status, but the path is created by your Apache configuration and can be changed.

Check whether the module is loaded

On many installations, list loaded modules and look for status_module:

apachectl -M | grep status

Some systems use the service-specific command:

httpd -M | grep status

If the module is built as a shared module but is not loaded, a manually managed installation may use a directive like this. Do not add it if the module is already loaded:

LoadModule status_module modules/mod_status.so

Module paths and configuration layouts vary. Debian and Ubuntu commonly provide a helper command:

sudo a2enmod status

Red Hat-family systems and manually managed installations commonly load modules through the main configuration or an included module file. Confirm the active configuration rather than assuming a particular file location.

Configure a protected status endpoint

Place the configuration in the main Apache configuration, a globally included configuration file, or the appropriate virtual-host context. The exact location depends on whether the endpoint should exist on one virtual host or across several hosts.

A local-only Apache 2.4 configuration is:

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

SetHandler server-status assigns the status handler to the URL. Require local allows requests from the local machine, which is suitable for local administration or a monitoring agent running on the same host.

To allow a dedicated internal monitoring host as well as local access:

<Location "/server-status">
    SetHandler server-status
    Require local
    Require ip 192.0.2.25
</Location>

The address 192.0.2.25 is documentation-only; replace it with the trusted monitoring address or private network used in your environment. Confirm the authorization behavior on your Apache version, especially when combining multiple Require directives. Use an explicit authorization block if your policy requires a particular logical combination.

Apache 2.4 uses Require directives. Older Apache 2.2 configurations may contain directives such as Order, Allow from, and Deny from. Treat those as migration context: do not copy legacy authorization syntax into a modern configuration without checking compatibility and behavior.

Enable detailed status information

ExtendedStatus On

ExtendedStatus adds more detailed request-level information to the status display, including data useful for identifying long-running requests. It can also expose request paths and client information, and collecting or displaying more detail may add overhead. Enable it only when needed and protect the endpoint tightly. Basic status is preferable when aggregate capacity information is sufficient.

Validate and reload

sudo apachectl configtest
sudo systemctl reload apache2

Some systems use httpd rather than apache2 as the service name. Always validate before reloading. If validation fails, Apache keeps using the previous active configuration or the service manager refuses the reload, depending on the platform and command used.

Access control, proxies, and remote administration

Access method	Example use case	Benefits	Risks or limitations
Localhost only	Administrator or agent on the Apache host	Smallest exposure; simple policy	Remote monitoring needs a local collector or secure tunnel
Trusted private address or subnet	Central monitoring server	Allows centralized collection	Requires accurate network boundaries and firewall rules
Authenticated administrative access	Remote operations team	Adds identity checks to network restrictions	Authentication configuration must be maintained securely
HTTPS through a controlled administrative proxy	Remote access from a management network	Encrypts credentials and status data	A proxy can accidentally publish the endpoint or alter the apparent source address

When a reverse proxy or load balancer fronts Apache, determine which address Apache sees as the request source. A proxy may make every request appear to come from the proxy itself, causing an expected monitoring address to fail authorization. Conversely, trusting forwarded client-address headers without a controlled trusted proxy can permit spoofing. Configure trusted proxy handling and network authorization deliberately, and test both allowed and denied paths.

For remote administrative access, use HTTPS and, where appropriate, an additional authentication layer, VPN, firewall policy, or mutually authenticated administrative network. Also inspect proxy routing rules so that a catch-all public virtual host cannot expose the endpoint.

Reading the human-readable status page

Request the standard page locally with:

curl --fail --silent http://127.0.0.1/server-status

The exact fields vary by Apache version, MPM, and configuration. Common sections are summarized below.

Field or section	Meaning	Operational interpretation	Caveats
Server version and build information	Apache version, platform, and build-related details	Useful for confirming the running software and investigating version-specific behavior	Reveals information that should not be public
Current time, restart time, and uptime	Current server clock and elapsed time since startup or restart	Short uptime may explain empty baselines or follow a deployment, crash, or configuration change	Check clock accuracy and distinguish graceful restarts from full restarts
Parent/server generation	Process-generation information associated with Apache restarts	Can help identify a graceful restart and old workers completing requests	Presentation differs between versions and MPMs
Total accesses and total traffic	Cumulative requests and bytes handled	Useful for broad traffic and throughput comparisons	Counters reset when the relevant server state restarts
Request rate and byte rate	Requests per second and response bytes per second	Shows current or recently calculated workload and throughput	Interpret over an interval; a short sample can be noisy
CPU usage	CPU consumed by Apache processes or workers where reported	High CPU can accompany expensive request processing or insufficient compute capacity	Compare with host-wide CPU, container limits, and other services
Busy workers	Workers currently handling or progressing connections or requests	Persistent values near the concurrency ceiling suggest saturation	Meaning depends on the MPM and connection behavior
Idle workers	Workers available and waiting for work	A healthy idle pool provides burst capacity; zero idle workers deserves investigation	Do not assume that more idle workers always improves performance
Scoreboard	Compact symbols representing worker states	Shows whether workers are reading, sending, waiting, closing, or stopping	Symbols and counts vary by MPM and version
Per-worker request table	Worker, client address, method, path, protocol, state, and timing details when available	Helps locate long-running requests, slow clients, and concentrated request paths	Usually requires extended status and can expose sensitive data

Busy and idle workers

A busy worker is handling or progressing a connection or request. An idle worker is available to accept work. When busy workers remain high and idle workers approach zero, Apache may be at its concurrency limit. This does not automatically mean that increasing the limit is correct: slow application dependencies, exhausted memory, CPU pressure, slow clients, or network constraints may be the real cause.

Scoreboard symbols

The scoreboard is a compact representation of Apache worker or process states. Common symbols include the following:

Symbol	Worker state	What it can indicate when persistent or excessive
`_`	Waiting for a connection	Normal idle capacity when present in a reasonable proportion
`R`	Reading a request	Slow clients, large request bodies, network problems, or request-reading pressure
`W`	Sending a reply	Large responses, slow clients, application latency, or output congestion
`K`	Keepalive connection	Many persistent connections; interpretation depends strongly on the MPM
`D`	DNS lookup	Reverse-DNS activity or lookup delays; verify whether such lookups are enabled
`C`	Closing connection	Connection teardown or clients that close slowly
`G`	Gracefully finishing	Workers completing existing work after a graceful restart
`I`	Idle cleanup of a worker	Normal worker lifecycle activity unless it persists unexpectedly
`.`	Open slot with no current process or thread	Unused capacity slot; exact meaning depends on the MPM and display version

Some versions display additional states or use different interpretations. Read a persistent pattern, not one snapshot. A large group of R workers suggests request-reading pressure; many W workers may indicate response or backend latency; many K workers require an MPM-aware interpretation.

Per-worker request details

When available, the request table associates a worker with a client address, HTTP method such as GET or POST, request path, protocol version, worker state, and connection or request timing. Use it to find paths that remain active unusually long or clients associated with slow connections. Redact this information when sharing diagnostics.

Machine-readable auto status output

Appending ?auto requests the plain-text auto status output, a format intended for scripts, agents, and monitoring collectors:

curl --fail --silent http://127.0.0.1/server-status?auto

Common fields include uptime, total accesses, total traffic, requests per second, bytes per second, busy workers, idle workers, and scoreboard data. Field names and availability vary with Apache version, loaded modules, configuration, and the active multiprocessing module.

A collector should tolerate missing or additional fields, validate numeric values, and attach useful labels such as host and environment without turning every request path into a high-cardinality metric. The endpoint can feed a shell script, monitoring agent, exporter, or dashboard. Protect the collector's access just as carefully as human access.

MPMs, worker models, and capacity limits

An MPM, or Multi-Processing Module, defines how Apache creates processes and threads. Status counts must be interpreted according to the active MPM.

MPM	Concurrency model	Worker terminology	Capacity directives to review	Status interpretation notes
prefork	Separate processes serve requests; each process generally handles one request at a time	Process-based workers	`MaxRequestWorkers`, `ServerLimit`, `StartServers`, `MinSpareServers`, `MaxSpareServers`	Memory per process is especially important; busy process counts near the limit indicate limited concurrency
worker	Multiple processes, with multiple threads per process	Threads are the important request-serving units	`MaxRequestWorkers`, `ServerLimit`, `ThreadsPerChild`, `StartServers`, `MinSpareThreads`, `MaxSpareThreads`	Process and thread counts must be read together; memory and thread capacity both matter
event	Threaded model designed to handle keep-alive connections more efficiently	Request workers plus connection-management behavior	`MaxRequestWorkers`, `ServerLimit`, `ThreadsPerChild`, `StartServers`, `MinSpareThreads`, `MaxSpareThreads`	Keep-alive connections may consume fewer request-processing resources than in other models, but active work can still saturate threads

MaxRequestWorkers is the maximum number of concurrent request-processing workers allowed by Apache. ServerLimit constrains process capacity in relevant MPMs, while ThreadsPerChild controls threads per process in threaded MPMs. StartServers controls initial process creation. Spare-server or spare-thread settings control how much idle capacity Apache maintains.

Do not tune these directives from server-status alone. Compare status with CPU, memory, file descriptors, disk latency, network saturation, backend services, and database metrics. Increasing concurrency can improve utilization, or it can multiply memory use and make an overloaded dependency fail faster.

Operational polling and alerting

A local capacity check can be performed as follows:

Request the local endpoint.
Compare BusyWorkers with IdleWorkers.
Inspect the scoreboard for a large concentration of active states.
Compare the result with host CPU, memory, load, network, and backend metrics before changing limits.

For centralized monitoring, authorize the monitoring host, retrieve /server-status?auto, parse the available fields, and store time-series values. Establish a normal baseline across quiet periods, busy periods, deployments, and expected traffic spikes before choosing thresholds.

Alert when there are no idle workers for a sustained interval.
Alert when busy workers remain close to the configured maximum.
Investigate an unexpectedly high request rate or rapidly increasing traffic.
Investigate long-running requests or a persistent concentration of R, W, or other active states.
Alert when the endpoint becomes unavailable, but distinguish an access-control failure from an Apache outage.

Troubleshooting with server-status

The scoreboard helps identify workers stuck reading requests, sending replies, waiting for connections, closing connections, or completing a graceful shutdown. It is a clue, not a diagnosis.

Observed status symptom	Likely causes	Additional evidence to collect	Potential response
All or nearly all workers are busy	Traffic spike, low concurrency limit, slow clients, slow upstream, CPU or memory exhaustion	Scoreboard, access and error logs, application timing, backend and host metrics	Identify the bottleneck before adjusting MPM limits; rate-limit or scale when appropriate
Many workers are reading requests	Slow clients, large uploads, network issues, request-reading attacks	Client addresses, request sizes, firewall and network data, request headers where safely logged	Review timeouts, upload design, network behavior, and abuse controls
Many workers are sending replies	Large responses, slow clients, application or upstream latency	Response sizes, access-log duration, upstream timing, network throughput	Find slow paths or clients; optimize responses or capacity as evidence supports
Many workers are in keep-alive state	Long-lived client connections or MPM-specific keep-alive behavior	Keep-alive settings, connection counts, MPM, client and load-balancer behavior	Review keep-alive policy and use event-MPM behavior appropriately
Workers remain in graceful shutdown	Long-running requests preventing old workers from exiting	Restart history, request table, access logs, application and upstream timing	Find the long requests and verify graceful-restart behavior
Long-running request rows	Slow application, database, upstream service, disk, network, or client	Access and error logs, application logs, database traces, CPU, memory, disk, and network metrics	Trace the request across dependencies instead of blaming Apache automatically

Common endpoint failures

404 Not Found: mod_status may be missing, the Location block may not be included, the configured path may differ, or a virtual host or reverse proxy may route the request elsewhere. Check loaded modules, search active configuration for SetHandler server-status, validate the configuration, and test the intended local listener.
403 Forbidden: The source address may not satisfy Require, a proxy may change the apparent address, or inherited authentication rules may deny access. Test locally, inspect authorization inheritance, and confirm the address Apache sees.
500 Internal Server Error: Review Apache's error log and configuration context. A handler, authorization, or version-specific directive may be invalid.
Missing module: Enable or load mod_status, then validate and reload. Avoid duplicate LoadModule directives.
Syntax error or reload failure: Run apachectl configtest, inspect error output, confirm that directives are allowed in their placement context, and correct the configuration before trying again.
Stale output after a failed reload: The running server may still be using its previous valid configuration. Confirm reload success and inspect the service manager and error logs rather than assuming the edited file is active.

Practical investigation workflows

Checking whether Apache has available capacity

Run curl --fail --silent http://127.0.0.1/server-status.
Compare busy and idle workers with the configured MPM limits.
Look for a persistent active-state pattern in the scoreboard.
Check CPU, memory, file descriptors, disk, network, application, and database metrics.
Change limits only after identifying whether Apache or a dependency is the limiting resource.

Collecting metrics

Allow only the monitoring agent or collector to access the endpoint.
Request the ?auto format.
Collect uptime, request rate, byte rate, busy workers, idle workers, and scoreboard information when useful.
Compare sustained conditions with a measured baseline and alert on trends rather than isolated samples.

Investigating intermittent slow responses

Enable ExtendedStatus On only for the trusted investigation window or trusted administrative audience.
Find workers that remain active for unusually long periods and note paths and client patterns.
Correlate those observations with access logs, error logs, application logs, upstream timing, and database metrics.
Determine whether the cause is Apache capacity, slow clients, an application dependency, the database, or host resource pressure.
Disable unnecessary detailed exposure after the investigation.

Verifying that the endpoint is not public

Bind authorization to localhost or explicitly trusted private monitoring addresses.
Test from an authorized local or monitoring source.
Test from an unauthorized external source and confirm denial rather than status data.
Review reverse-proxy and load-balancer rules to ensure the administrative path is not published.

Key exam and operations notes

mod_status provides the status handler; server-status is the common URL path.
ExtendedStatus On provides more request-level detail but increases privacy and exposure concerns.
BusyWorkers near MaxRequestWorkers indicates possible saturation, not proof that the limit should be raised.
The scoreboard is MPM- and version-dependent; interpret symbols with the active process and thread model.
Use Apache 2.4 Require authorization syntax on current installations.
Use logs and host, backend, and database metrics to validate conclusions drawn from a status snapshot.
A graceful restart lets existing requests finish while new workers use updated configuration; old workers can therefore remain visible while draining.

For a protected operational view, see Apache Server Status. Keep the endpoint restricted, measure a baseline, and use it as one evidence source in a broader monitoring system.