HAProxy Ingress is a Kubernetes Ingress controller backed by HAProxy — one of the most battle-tested TCP/HTTP load balancers in the world. It's favored for high-throughput environments where connection draining, fine-grained timeouts, and ACL-based routing matter. But when HAProxy Ingress fails, it takes every application it routes with it.
This tutorial shows you how to set up external uptime monitoring for HAProxy Ingress using Vigilmon — free tier, no credit card required.
Why HAProxy Ingress needs external monitoring
HAProxy Ingress concentrates your cluster's inbound traffic through a small number of highly configured pods. Failures are often silent from the inside:
- HAProxy backend removed from rotation — a backend server hits its max-connection threshold; HAProxy marks it down in its internal health check, but Kubernetes reports the pod as
RunningandReady - Config template render failure — a bad Ingress annotation causes the HAProxy config template to produce invalid syntax; the controller falls back to the last known good config, silently routing stale traffic
- Connection drain window expires — during a rolling update, the drain timeout is hit and active connections are forcibly closed; requests in flight get TCP RSTs that users see as errors
- ACL collision — two Ingress resources define conflicting ACL rules; the last-writer-wins without any error, and one application stops receiving traffic
- Lua plugin crash — custom Lua scripts used for header manipulation or authentication can panic the HAProxy process without restarting the controller pod
- TLS handshake failure after cert rotation — HAProxy caches TLS session tickets; after a cert rotation the old ticket keys remain in memory and cause session resumption failures for some clients
What you'll need
- A Kubernetes cluster with HAProxy Ingress installed (via Helm or manifests)
- At least one application exposed via an Ingress resource with
ingressClassName: haproxy - A free Vigilmon account
Step 1: Verify HAProxy Ingress is reachable
kubectl get svc -n haproxy-controller
# NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S)
# haproxy-ingress LoadBalancer 10.96.50.10 203.0.113.20 80:31080/TCP,443:31443/TCP
Test that a backend application responds through the ingress:
INGRESS_IP=203.0.113.20
curl -H "Host: myapp.example.com" http://$INGRESS_IP/health
# {"status":"ok"}
If using HTTPS:
curl -H "Host: myapp.example.com" https://myapp.example.com/health
# {"status":"ok"}
Step 2: Add an HTTP monitor in Vigilmon
For each application exposed through HAProxy Ingress, create a Vigilmon monitor:
- Log in to vigilmon.online and go to Monitors → New Monitor
- Choose HTTP / HTTPS
- Set the URL to your application's health endpoint:
https://myapp.example.com/health - Set Expected status code to
200 - Optionally add a Response body check:
"status":"ok" - Set the check interval to 1 minute
- Save
Repeat for every critical application routed through HAProxy Ingress.
Why not just monitor the HAProxy stats page?
HAProxy exposes a stats page (usually at :1936/haproxy_stats). It's useful for internal dashboards but not a substitute for external monitoring. The stats page can report all backends as healthy while an external routing problem prevents users from reaching those backends. External monitoring from Vigilmon's global probe network tests what users actually experience.
Step 3: Monitor TCP health for high-stakes backends
HAProxy Ingress is often chosen precisely because it handles raw TCP traffic well. If you expose TCP services via the controller's TCP service configmap, add TCP monitors in Vigilmon:
# ConfigMap for TCP passthrough
apiVersion: v1
kind: ConfigMap
metadata:
name: haproxy-ingress-tcp
namespace: haproxy-controller
data:
"5432": "production/postgres:5432"
Then in Vigilmon:
- Go to Monitors → New Monitor
- Choose TCP Port
- Enter host:
203.0.113.20, port:5432 - Save
This detects HAProxy TCP proxy failures independently of HTTP monitoring.
Step 4: Monitor SSL certificate expiry
HAProxy Ingress handles TLS termination. Add SSL expiry monitoring for every hostname:
- In Vigilmon, create an HTTPS monitor for your domain
- Enable SSL certificate expiry alerts
- Set a 14-day warning threshold
This is especially important in HAProxy setups where certificates are bundled into the HAProxy configuration rather than being picked up dynamically — a missed cert rotation can silently serve an expired cert.
Step 5: Configure alert channels
Email alerts
- Go to Alert Channels → Add Channel → Email
- Add your infrastructure on-call email
- Assign to all HAProxy Ingress monitors
Webhook (Slack / PagerDuty)
- Go to Alert Channels → Add Channel → Webhook
- Enter your webhook URL
- Assign to all monitors
Correlating alerts with HAProxy state
When an alert fires:
# Check HAProxy Ingress controller pods
kubectl get pods -n haproxy-controller
# View recent logs for reload or config errors
kubectl logs -n haproxy-controller -l run=haproxy-ingress --tail=100 | \
grep -iE "error|warn|reload|backend"
# Check Ingress resources for annotation issues
kubectl get ingress -A
kubectl describe ingress myapp -n production
# Verify backend endpoints are registered
kubectl get endpoints myapp -n production
If the Vigilmon alert fires but kubectl shows pods as Running, the problem is outside the cluster — likely the cloud load balancer, DNS, or network routing.
Step 6: Create a status page
- In Vigilmon, go to Status Pages → New Status Page
- Name it "Platform Services"
- Add all application monitors routed through HAProxy Ingress
- Group by team or service tier
- Publish
Monitoring summary
| Monitor | Type | What it catches |
|---------|------|-----------------|
| https://myapp.example.com/health | HTTP | App down, HAProxy backend removed from rotation |
| https://api.example.com/v1/status | HTTP | ACL routing collision, path misconfiguration |
| TLS cert for each hostname | SSL expiry | Certificate expiry, rotation failure |
| 203.0.113.20:5432 | TCP | TCP passthrough proxy failure |
What's next
- Canary testing — use HAProxy Ingress weight annotations to split traffic and add separate Vigilmon monitors for each backend to verify canary stability
- Connection rate limits — add monitors with expected 429 responses to verify that rate-limit ACLs are active
- Drain verification — after a rolling deployment, use Vigilmon's incident history to verify that no requests were dropped during the drain window
Get started free at vigilmon.online — no credit card, monitors start running in under a minute.