Network & Proxy Services
    Updated May 2026
    HAProxy logo

    HAProxy Monitoring

    Monitor HAProxy backend health, session rate vs limit, queue depth, response time, and per-server `status` in real time — via the stats socket, `/stats` page, or native Prometheus exporter.

    Start Free TrialView Docs

    Why monitor HAProxy?

    HAProxy sits at the front of your traffic — every request flows through it before reaching any backend. Backend failures, dropped sessions, and queue buildup show up at HAProxy first, minutes before downstream services start paging on-call. Monitoring catches incidents at the entry point.

    Auto-discovery via Xitogent — no manual configuration required
    Real-time backend and frontend session metrics
    Backend server health status and availability tracking
    Response time and error rate monitoring per backend
    Connection queue length and retry tracking
    HTTP response code distribution analysis
    Works on both Linux and Windows servers
    1-minute metric collection intervals
    What is HAProxy monitoring?

    HAProxy monitoring, explained

    HAProxy monitoring catches backend failures, dropped sessions, and queue buildup before they take down the services HAProxy is fronting. Because HAProxy sits at the front of your stack, monitoring it well usually means catching incidents at the entry point — minutes before a downstream service starts paging on-call. Xitoring auto-discovers your HAProxy, reads from the stats socket, /stats page, or native Prometheus exporter (whichever you've enabled), and routes alerts to your existing notification channels.

    Metrics

    What we monitor

    Session Rate

    Number of new sessions per second across frontends and backends.

    Active Sessions

    Currently active sessions and connection count per proxy.

    Backend Health

    Health status (UP/DOWN) and check duration for each backend server.

    Response Time

    Average and max response time per backend server.

    Error Rate

    Connection errors, response errors, and denied requests.

    Queue Length

    Number of requests waiting in backend queues.

    Bytes In/Out

    Network throughput per frontend and backend.

    HTTP 4xx/5xx

    Distribution of HTTP response codes indicating client and server errors.

    Retries

    Connection retry count indicating backend instability.

    Session Limit

    Current sessions vs configured session limits per proxy.

    Connection Rate

    New TCP connections per second to each frontend.

    Denied Requests

    Requests denied by ACLs or rate limiting rules.

    Triggers & Alerts

    Configurable alert triggers

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

    HAProxy monitoring trigger configuration dashboard

    Backend Down

    critical

    Fires when a backend server goes DOWN, reducing capacity and risking overload on remaining servers.

    Response Time

    warning

    Triggers when average response time exceeds threshold, indicating backend performance degradation.

    Session Rate

    warning

    Alerts when session rate spikes beyond normal baseline, indicating traffic surges.

    Error Rate

    critical

    Fires when connection or response error rate exceeds threshold across backends.

    Queue Length

    warning

    Triggers when requests queue up waiting for backend capacity.

    Session Limit

    critical

    Alerts when active sessions approach the configured maximum limit.

    01

    Importance of HAProxy Monitoring

    HAProxy sits at the critical path of your traffic — every request passes through it. Without monitoring, backend failures, session saturation, and response time spikes can silently degrade your entire application's availability and user experience.

    • Detect backend server failures before they impact users
    • Monitor response times to catch performance degradation early
    • Track session rates to plan capacity for traffic surges
    • Identify error patterns across backends and frontends
    • Ensure load distribution remains balanced across servers
    HAProxy monitoring dashboard with backend health and response times
    HAProxy traffic analytics and error tracking
    02

    Why Choose Xitoring

    Xitoring delivers enterprise-grade HAProxy monitoring with zero-config setup. Our lightweight agent auto-discovers your HAProxy instance, 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, proxies, and uptime
    • Flexible alerting via Slack, PagerDuty, Telegram & more
    • Historical data retention for capacity planning & audits
    Xitoring HAProxy monitoring overview
    Alert notification and escalation configuration
    Use cases

    Common HAProxy monitoring scenarios

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

    Keeping a database online during failures

    HAProxy decides which database to send traffic to when the main one fails. If it doesn't notice the failure quickly — or sends traffic to a struggling backup — the app goes down anyway. We watch the handoff signals so failover does what it's supposed to: stay invisible to users.

    Traffic gateway for an app or API

    When HAProxy sits in front of an app or API, it sees every request and error before anything else does. We surface the patterns — slow services, rising errors, request backups — so the team knows exactly which piece to fix instead of guessing during an incident.

    Entry point for a Kubernetes app

    In Kubernetes, HAProxy is often the door to your entire app. A misstep there — a bad config push, a failing rollout — can briefly take everything offline. We catch the warning signs early so routine deployments don't turn into customer-visible outages.

    Before you start

    Prerequisites for HAProxy

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

    • HAProxy 2.x or 3.x running on the server (HAProxy Enterprise also supported)
    • One of: a stats socket (stats socket /var/run/haproxy.sock), the built-in HTTP stats page, or the native Prometheus exporter at /metrics (HAProxy 2.0+ with USE_PROMEX)
    • Read access to the stats source for the Xitogent user
    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 the HAProxy stats socket or page

    Xitogent collects metrics via the HAProxy stats interface. Ensure the stats socket is configured:

    # In haproxy.cfg: listen stats bind localhost:8404 stats enable stats uri / # Then provide http://127.0.0.1:8404 to xitogent integrate
    3

    Enable the HAProxy integration

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

    sudo xitogent integrate
    4

    Configure alert thresholds (optional)

    Set custom thresholds for backend health, response time, or session count 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 HAProxy monitoring — flat pricing, deeper integrations, and one agent that covers your whole stack.

    See all comparisons

    Frequently asked questions

    What is HAProxy monitoring?
    HAProxy monitoring is the continuous collection of HAProxy load-balancer metrics — `sess_rate`, `scur` vs `slim`, `qcur`, throughput, error counters, HTTP response code distribution, per-backend `status`, and check failures — plus alerting when those metrics breach thresholds. Because HAProxy sits at the entry point to your stack, monitoring it is monitoring every backend it fronts.
    How do I enable the HAProxy stats socket?
    Add `stats socket /var/run/haproxy.sock mode 660 level admin` to the `global` section of `haproxy.cfg`, reload HAProxy (`systemctl reload haproxy`), and verify with `echo "show stat" | socat stdio /var/run/haproxy.sock`. Xitogent then reads CSV output from the same socket on a 1-minute interval.
    What metrics does the HAProxy stats page display?
    The `/stats` page (HTML or CSV via `;csv`) exposes: session counts (`scur`/`smax`/`slim`/`stot`), session rate (`sess_rate`), queue depth (`qcur`/`qmax`), throughput (`bin`/`bout`), errors (`ereq`/`econ`/`eresp`), retries (`wretr`/`wredis`), HTTP status distribution (`hrsp_1xx`–`hrsp_5xx`), per-server `status`/`weight`/`act`/`bck`, and check telemetry (`chkfail`/`lastchg`/`downtime`). Xitogent surfaces all of them.
    How do I monitor HAProxy backend health and response time?
    Per-server `status` (UP / DOWN / NOLB / MAINT) plus `chkfail` (consecutive failed health checks) and `lastchg` (seconds since last state change) are the core health signals. For latency, use `rtime` (last 1024-request average response time) per backend server. Alerts on `status != UP` and `rtime > baseline × 2` catch most backend-failure modes.
    Can I monitor HAProxy with Prometheus natively?
    Yes — HAProxy 2.0+ ships a built-in Prometheus exporter at `/metrics`, enabled via `frontend stats { bind:8404; http-request use-service prometheus-exporter if { path /metrics }; }`. No sidecar exporter needed. Xitogent reads either the native exporter or the legacy stats socket — whichever you've enabled.
    What is the difference between the stats socket and the HTTP stats page?
    The stats socket (`/var/run/haproxy.sock`) is the Runtime API — it accepts read commands (`show stat`, `show backend`, `show sess`) AND control commands (`set server`, `disable server`, `enable server`) for live operations like draining traffic. The HTTP stats page is read-only and aimed at humans/agents. Most monitoring tools use the socket because it's more efficient and exposes the full metric set.
    How do I track session rate vs session limit in HAProxy?
    `sess_rate` (current new sessions/sec) and `scur` vs `slim` (current vs max sessions) are the two saturation signals. Alert when `scur / slim > 0.8` per frontend or backend — that's your headroom warning before HAProxy starts rejecting connections. `smax` (peak observed) helps you size `maxconn` correctly.
    How do I use the HAProxy Runtime API to drain traffic from a server?
    Connect to the stats socket and send `set server / state drain` (or `maint` for full removal). The server stops accepting new connections but lets in-flight ones complete. Xitogent surfaces server state changes in real time, so you can see when traffic has fully drained before maintenance work.
    What HAProxy versions are supported?
    HAProxy 2.x (including 2.6 LTS, 2.8 LTS) and 3.x are fully supported, plus HAProxy Enterprise. The integration auto-detects whether you've enabled the stats socket, the HTTP stats page, or the native Prometheus exporter and adapts accordingly. Older 1.8/1.9 versions work with reduced metric coverage (no native Prometheus support).

    Start monitoring HAProxy today

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

    Start Free Trial

    Keep exploring

    Related Integrations