Web & Application Servers
    Updated May 2026
    Apache logo

    Apache Monitoring

    Monitor Apache HTTP Server requests/sec, BusyWorkers vs IdleWorkers, BytesPerSec, async connection states, and CPULoad in real time — agent-based via `mod_status` and `?auto`.

    Start Free TrialView Docs

    Why monitor Apache?

    Apache HTTP Server still runs a huge slice of the web — cPanel/WHM hosting, WordPress, Drupal, and CDN origins. When workers saturate, CPU spikes, or one noisy vhost starts consuming the pool, every site on the box slows down. Monitoring surfaces the offender before you have to ssh in at 3am.

    Auto-discovery via Xitogent — no manual configuration required
    Real-time metrics from Apache mod_status
    Track request rates, throughput, and connection states
    Customizable alert thresholds for every metric
    Historical data retention for trend analysis
    Works on both Linux and Windows servers
    CLI and dashboard management options
    1-minute metric collection intervals
    What is Apache monitoring?

    Apache monitoring, explained

    Apache monitoring catches worker-pool saturation, CPU spikes, and slow-response patterns before they cascade into 503s. On shared cPanel/WHM hosting or any multi-vhost setup, it's also how you find the one noisy account consuming workers from everyone else — without sshing into the box at 3am. Xitoring auto-discovers your Apache, polls /server-status?auto on a 1-minute interval, and routes alerts to Slack, PagerDuty, Telegram, or whatever your team already uses.

    Metrics

    What we monitor

    Total Requests

    Total number of HTTP requests processed since the server started.

    Requests per Second

    Current rate of incoming HTTP requests hitting your server.

    Bytes per Second

    Data throughput rate measuring how much data Apache is serving.

    Bytes per Request

    Average response size per request, useful for detecting payload anomalies.

    Busy Workers

    Number of worker threads actively processing requests.

    Idle Workers

    Number of worker threads waiting for incoming requests.

    Connections Total

    Total number of connections accepted by the server.

    Connections Async Writing

    Connections in async write state, waiting to send data to clients.

    Connections Async Keep-Alive

    Connections held open in keep-alive state for potential reuse.

    Connections Async Closing

    Connections in the process of being gracefully closed.

    Server Uptime

    Total time the Apache server has been running without restart.

    CPU Load

    Percentage of CPU consumed by Apache worker processes.

    Triggers & Alerts

    Configurable alert triggers

    Set up custom triggers in your dashboard to get notified the moment Apache metrics cross your defined thresholds.

    Apache monitoring trigger configuration dashboard

    Busy Workers

    warning

    Fires when the number of active worker threads exceeds your threshold, indicating the server is under heavy load and may start queuing requests.

    Idle Workers

    critical

    Triggers when idle workers drop below a minimum, meaning the server has little spare capacity to handle incoming traffic spikes.

    Requests per Second

    warning

    Alerts when the request rate exceeds normal baselines, useful for detecting traffic surges, DDoS patterns, or runaway bots.

    CPU Load

    critical

    Fires when Apache's CPU consumption crosses your defined limit, signaling resource contention that could degrade response times.

    Bytes per Second

    warning

    Triggers on abnormal throughput — either unusually high (possible data exfiltration) or low (upstream issues).

    Server Uptime Reset

    critical

    Detects when the server uptime counter resets to zero, indicating an unexpected Apache restart or crash event.

    01

    Importance of Apache Monitoring

    Apache powers over 30% of all active websites globally. Without proper monitoring, performance degradation, traffic spikes, and resource exhaustion can go undetected — leading to downtime, lost revenue, and poor user experience.

    • Detect slow response times before they impact end users
    • Identify memory leaks and resource exhaustion early
    • Prevent cascading failures across your infrastructure
    • Maintain SLA compliance with real-time visibility
    • Correlate Apache metrics with upstream application performance
    Apache monitoring dashboard with real-time metrics
    Server downtime alert and incident timeline
    02

    Why Choose Xitoring

    Xitoring delivers enterprise-grade Apache monitoring with zero-config setup. Our lightweight agent auto-discovers your Apache instances, starts collecting metrics in under 60 seconds, and integrates with your existing notification channels.

    • One-command install — no complex YAML or config files
    • 15+ global monitoring nodes for low-latency checks
    • Unified dashboard for servers, services, and uptime
    • Flexible alerting via Slack, PagerDuty, Telegram & more
    • Historical data retention for capacity planning & audits
    Xitoring multi-server monitoring overview
    Notification channels and alert configuration
    Use cases

    Common Apache monitoring scenarios

    Where Apache typically runs today — and what could go wrong if no one's watching.

    Busy WordPress or eCommerce hosting

    When dozens of websites share the same server — the usual setup for hosting companies and agencies — one noisy site can starve every other site on the box. We catch the early warning signs so the team can act before customers ever see a slow or broken page.

    Website behind a CDN like Cloudflare

    A CDN absorbs traffic spikes, but the original web server still has to be healthy — and CDN dashboards don't tell you when it isn't. We watch the source-of-truth signals from your own server so a quiet origin slowdown can't degrade the whole site.

    Web server passing traffic to apps behind it

    When Apache hands requests off to an internal application, the slow piece is usually that app — not Apache itself. We separate the two so you instantly know whether to investigate the web layer or the app behind it, instead of chasing the wrong thing during an incident.

    Before you start

    Prerequisites for Apache

    Make sure you've got these in place — most installs are a 60-second job once they are.

    • Apache 2.4 or later (2.5/trunk also supported) running on the server
    • mod_status enabled with ExtendedStatus On and the /server-status?auto endpoint reachable from localhost
    • sudo / root access to install Xitogent and read the Apache config
    Setup Guide

    Get started in minutes

    1

    Install Xitogent on your server

    If you haven't already, install the lightweight Xitogent monitoring agent on your server.

    curl -s https://xitoring.com/install.sh | sudo bash -s -- --key=YOUR_API_KEY
    2

    Enable mod_status in Apache

    Ensure mod_status is enabled and accessible locally. Add the following to your Apache configuration:

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

    Enable the Apache integration

    Use the Xitoring dashboard or CLI to enable the Apache integration. Xitogent will auto-detect your Apache instance.

    sudo xitogent integrate
    4

    Configure alert thresholds (optional)

    Set custom thresholds for metrics like busy workers, request rate, or CPU load to get notified when something needs attention.

    5

    Verify it's working

    Run this command on the server to confirm Xitogent picked up the integration. Fresh metrics will start streaming to your dashboard within ~30 seconds.

    sudo xitogent status
    Compare

    Considering alternatives?

    See how Xitoring stacks up against the alternatives for Apache monitoring — flat pricing, deeper integrations, and one agent that covers your whole stack.

    See all comparisons

    Frequently asked questions

    What is Apache monitoring?
    Apache monitoring is the continuous collection of Apache HTTP Server performance data — `BusyWorkers`, `IdleWorkers`, requests/sec, bytes/sec, async connection states, CPULoad, and uptime — plus alerting when those metrics breach thresholds. The data comes from `mod_status` (with `ExtendedStatus On`), exposed at `/server-status?auto` for machine-readable polling.
    How do I enable mod_status in Apache?
    Load the module (`LoadModule status_module modules/mod_status.so`), turn on `ExtendedStatus On`, then add a Location block: ` SetHandler server-status; Require local; `. Reload Apache (`apachectl graceful`) and verify with `curl http://127.0.0.1/server-status?auto`. Xitogent then polls the same endpoint on a 1-minute interval.
    What is the difference between mod_status and ExtendedStatus?
    `mod_status` is the Apache module that exposes the `/server-status` endpoint. `ExtendedStatus` is a directive inside that module — when `Off` (the default in some distros) you get only basic counters; when `On` you get full per-request detail including CPU usage, request methods, and host info per worker. For meaningful monitoring, set `ExtendedStatus On`.
    How do I monitor Apache prefork vs worker vs event MPM?
    All three MPMs expose the same `mod_status` counters, but the saturation thresholds differ. `prefork` saturates at `MaxRequestWorkers` (one process per request). `worker` and `event` use threads-per-process and scale to thousands of concurrent connections. Xitogent detects the active MPM and adjusts worker-saturation alerts so you don't get false positives on event-MPM servers handling many keep-alive connections.
    How do I access server-status in machine-readable format?
    Append `?auto` to the URL: `/server-status?auto`. The output is plain text with `key: value` pairs (Total Accesses, Total kBytes, CPULoad, Uptime, ReqPerSec, BytesPerSec, BytesPerReq, BusyWorkers, IdleWorkers, ConnsTotal, ConnsAsyncWriting/KeepAlive/Closing, plus per-worker scoreboard). Every monitoring agent — Xitogent — reads this format.
    How do I log real client IPs when Apache is behind a CDN?
    Use `mod_remoteip` (built into Apache 2.4+). Configure `RemoteIPHeader X-Forwarded-For` and `RemoteIPTrustedProxy` with the IP ranges of your CDN or load balancer. Apache then rewrites the connection's remote address from the trusted-proxy header, so access logs and `mod_status` per-request data show real client IPs instead of the CDN edge.
    Will this integration affect Apache performance?
    No measurable impact. Xitogent reads the `/server-status?auto` endpoint with the same lightweight mechanism Apache's own monitoring tools use. There is no instrumentation injected into the request path, and the polling interval (60 seconds by default) generates negligible load.
    Can I monitor multiple Apache instances on one server?
    Yes. If you're running multiple Apache instances on different ports (or on different listeners for multi-tenant hosting), configure Xitogent with each `/server-status?auto` endpoint — every instance is tracked separately in the dashboard with its own metrics, alerts, and history.
    What Apache versions are supported?
    Apache HTTP Server 2.2, 2.4 (current stable), and the 2.5/trunk development builds are all supported. `mod_status` semantics are stable across versions, so the integration is forward-compatible. The integration runs identically on Linux and Windows builds of Apache.

    Start monitoring Apache today

    Set up in under 60 seconds. No credit card required. Full metrics from day one.

    Start Free Trial

    Keep exploring

    Related Integrations