WHM Apache Status Fails While Apache Is Running: What to Check

WHM says “Failed to receive status information from Apache”, yet the websites still load. Before reaching for a restart, separate two questions: is Apache serving traffic, and can WHM retrieve its status report?

Those checks are not interchangeable. A working web server can return the wrong response for its monitoring URL. The following investigation is for a cPanel/EasyApache server with root access, not for a shared-hosting account. The aim is to identify the failed request before changing the service.

Check the service without restarting it

systemctl is-active httpd
/usr/local/cpanel/scripts/restartsrv_httpd --status
apachectl -t
apachectl -M | grep status

Look for an active service, a running process in cPanel's status check, a successful syntax test and a loaded status_module. The --status argument does not restart Apache.

If the service is down, or the syntax test fails, follow that evidence first. If both checks pass, repeatedly testing whether Apache exists will not explain the missing report. Move on to the HTTP request. The mod_status documentation describes the reporting endpoint and its machine-readable output.

Watch one failed request

Start this read-only log view, open Apache Status in WHM once, then stop the view with Ctrl+C:

tail -n 0 -f /etc/apache2/logs/access_log /etc/apache2/logs/error_log

Find the local request that corresponds to the page load. Apache's recurring OPTIONS * internal connections are not the report itself. Likewise, a warning from an unrelated website is not a cause simply because it appeared at the same time.

• 403: inspect the access rule or security layer refusing the request.
• 404: an HTTP server answered, but the request did not reach the status handler. Check the URL, virtual host and loaded configuration.
• 200: inspect the body too. A website's ordinary HTML page is not a valid status report.

Do not assume the endpoint is always /whm-server-status. cPanel documents a randomized status path and the problems caused by older custom templates in its custom-template advisory. Keep the actual private path out of public screenshots and support posts.

Is the running configuration the one you inspected?

apachectl -V | grep -E 'HTTPD_ROOT|SERVER_CONFIG_FILE'
grep -n -B 8 -A 20 'SetHandler server-status' /etc/apache2/conf/httpd.conf
stat -c '%y %n' /etc/apache2/conf/httpd.conf
ps -C httpd -o pid,ppid,lstart,args

Verify the configuration path before interpreting its contents. The file shown here is a common EasyApache location; examining a different installation's file tells you little about the process answering your request. In the status block, compare the Location path with the requested URL and inspect the local access permissions.

A configuration file modified after the parent process started is a useful clue, not proof that no reload happened. A graceful reload can leave the parent PID unchanged. Treat process age and file time as context rather than a verdict.

In the incident behind this guide, Apache was active, the status module was loaded and the correct handler appeared in the file. The local status request nevertheless returned 404. After a successful syntax test, a graceful reload restored the WHM report. That outcome supports checking for unapplied configuration changes; it does not make a reload the universal cure for a missing URL.

Reload only after reviewing what it will load

If the handler definition is correct, the configuration test passes and you understand any pending changes, a controlled reload is a reasonable next step:

apachectl -t && apachectl -k graceful

This changes the running server. It attempts to let existing requests finish while loading the configuration; it is not an unconditional promise of zero disruption. A long-running worker may need separate attention. Apache explains the behavior in its restart documentation.

If the generated configuration itself is outdated, reloading it cannot supply a missing definition. Check the runtime package and available updates:

rpm -q ea-apache24-config-runtime
dnf list --upgrades ea-apache24-config-runtime

cPanel lists an outdated runtime package as one possible cause. Review repository health and supported template changes rather than manually patching generated configuration. Do not disable the entire web application firewall or expose server-status publicly to make the error disappear.

Verify the response, not just the panel

Replace the placeholder below with the actual path from your configuration. This makes a local request without sending traffic through a proxy:

curl --noproxy '*' -sS --max-time 10 \
  -o /dev/null -w 'HTTP %{http_code}\n' \
  'http://127.0.0.1/STATUS_PATH?auto'
systemctl is-active httpd

After receiving HTTP 200, repeat the request without -o /dev/null and -w to inspect the counters. Check the WHM report, website responses and error log as well. If the local endpoint still returns 404, investigate virtual hosts and included configuration instead of repeating graceful reloads.