Monitoring Load Balancers for Uptime and Health

A load balancer is the front door to your infrastructure. All user traffic passes through it before reaching your application servers. If the load balancer fails — or if it's routing traffic to unhealthy backends — users can't reach your service. Monitoring the load balancer is as critical as monitoring the application behind it.

What Load Balancers Do (and How They Fail)

Load balancers distribute incoming traffic across multiple backend servers. They also:

• Perform health checks on backends and remove unhealthy ones from rotation
• Terminate SSL/TLS (for Application Load Balancers)
• Provide DDoS protection and rate limiting
• Route based on URL path, headers, or geographic location

Failure modes:

• Load balancer itself goes down — complete outage; all backends unreachable
• All backends fail health checks — load balancer is up but has nowhere to route traffic
• SSL certificate expires — if the load balancer terminates TLS, expired cert causes failures
• Configuration error — routing rule change routes traffic to wrong backend
• Capacity exhaustion — too many connections overwhelm the load balancer

External HTTP Monitoring: The Foundation

Monitor the load balancer endpoint (your public domain or IP) externally:

Monitor: https://yourdomain.com
Expected status: 200
Interval: 1 minute

This validates the complete path: DNS → load balancer → backend pool → application. If any component fails, this check catches it.

For multi-location monitoring, check from multiple geographic regions — CDN/anycast issues can affect availability regionally.

Load Balancer Health Checks for Backends

Configure health checks on your load balancer to detect backend failures:

AWS Application Load Balancer (ALB)

{
    "HealthCheckProtocol": "HTTP",
    "HealthCheckPath": "/health",
    "HealthCheckPort": "traffic-port",
    "HealthCheckIntervalSeconds": 30,
    "HealthCheckTimeoutSeconds": 5,
    "HealthyThresholdCount": 2,
    "UnhealthyThresholdCount": 3
}

When all backends fail health checks, the ALB returns 502 Bad Gateway to all requests — detectable by your external monitor.

Nginx (as a Load Balancer)

upstream backend {
    server app1:8080;
    server app2:8080;
    
    # Active health checks (Nginx Plus only)
    # For open-source: use passive health checking
}

For open-source Nginx, health checking is passive — failed requests are detected as they occur. Nginx Plus supports active health checks.

HAProxy

backend app_servers
    option httpchk GET /health
    http-check expect status 200
    server app1 192.168.1.10:8080 check inter 10s fall 3 rise 2
    server app2 192.168.1.11:8080 check inter 10s fall 3 rise 2

HAProxy's active health checking removes backends from rotation on failure and adds them back when they recover.

Monitoring SSL at the Load Balancer

If your load balancer terminates SSL (common with ALB, Nginx, HAProxy), monitor the certificate:

Monitor type: SSL certificate
Domain: yourdomain.com (points to load balancer)
Alert at: 30 days remaining

An expired certificate at the load balancer prevents all traffic from reaching your backends, regardless of backend health.

See SSL certificate monitoring for complete setup.

AWS ALB Monitoring with CloudWatch

For AWS ALBs, configure CloudWatch alarms:

# Alert when all backends are unhealthy
aws cloudwatch put-metric-alarm \
    --alarm-name "ALB-HealthyHostCount" \
    --metric-name HealthyHostCount \
    --namespace AWS/ApplicationELB \
    --dimensions Name=LoadBalancer,Value=app/your-alb/xxxx \
    --period 60 \
    --evaluation-periods 2 \
    --threshold 1 \
    --comparison-operator LessThanThreshold \
    --alarm-actions arn:aws:sns:...

Key ALB metrics to monitor:

• HealthyHostCount — alert if count drops to 0
• UnhealthyHostCount — alert if count rises above 0
• HTTPCode_ELB_5XX_Count — alert on 5xx errors from the ALB itself
• TargetResponseTime — alert on high latency

Response Time Monitoring

Load balancers add minimal latency in healthy conditions. If you see response time increasing in your uptime monitoring data, it may indicate:

• Backend servers under load (taking longer to respond)
• Load balancer routing to only healthy backends (pool reduced)
• SSL handshake performance issues

Response time trends visible in your monitoring tool's historical data help diagnose these patterns.

Combined Load Balancer Monitoring Stack

The external HTTP monitor from Domain Monitor is your user-perspective check — the others provide internal visibility. Both layers are necessary for complete coverage.

Monitor your load balancer and application stack from outside your infrastructure at Domain Monitor.

Related Articles

• "Monitoring Microservices: Uptime and Health Across Distributed Services"
• "Monitoring WooCommerce Stores: Uptime, SSL and Checkout Health"
• "How to Choose Your Uptime Monitoring Check Frequency"