Overview
Health monitors continuously probe pool members and automatically remove unhealthy instances from rotation. When a member fails the configured number of consecutive probes, it is markedOFFLINE and receives no traffic until it recovers. This guide covers all
supported monitor types, their configuration parameters, and best practices for different
application types.
Prerequisites
- An active Xloud account with appropriate permissions
- Access to the Xloud Dashboard (
https://connect.<your-domain>) or CLI configured with credentials - API credentials sourced (
source admin-openrc.sh)
Supported Monitor Types
| Type | Protocol | Use Case |
|---|---|---|
TCP | Layer 4 connection check | Any TCP service — databases, custom protocols |
HTTP | GET request + response code check | Web applications and REST APIs |
HTTPS | Encrypted GET request check | HTTPS backends requiring secure probes |
PING | ICMP echo | Basic host reachability test |
UDP-CONNECT | UDP connection check | UDP-based services |
TLS-HELLO | TLS handshake check | Verify TLS is functional without full HTTPS probe |
Configuration Parameters
| Parameter | Description | Recommended |
|---|---|---|
| Delay | Seconds between consecutive probes | 5–10 |
| Timeout | Seconds to wait for probe response before counting as failed | 3–5 |
| Max Retries | Consecutive failures before marking member DOWN | 3 |
| Max Retries Down | Consecutive successes before restoring a DOWN member to ONLINE | 3 |
| URL Path | Path for HTTP/HTTPS monitors (must return expected code) | /health |
| Expected Codes | Comma-separated HTTP status codes accepted as healthy | 200 |
Create a Health Monitor
- Dashboard
- CLI
Navigate to pool health monitor
Open your load balancer, select the Pools tab, and click the pool name.
Select the Health Monitor sub-tab. Click Create Health Monitor.
Select monitor type
Select the type that matches your backend service. HTTP is appropriate for web
applications; TCP is appropriate for databases and custom protocols.
Set timing parameters
| Field | Recommended Value |
|---|---|
| Delay | 10 |
| Timeout | 5 |
| Max Retries | 3 |
For HTTP monitors, set URL Path to a dedicated health endpoint (e.g., /health) | |
| that returns HTTP 200 only when the application is fully ready. |
View Member Health Status
After creating a health monitor, verify members are being probed and showing the correct operating status:List member operating status
All members show
ONLINE operating status — they are healthy and receiving traffic.Manage Health Monitors
Health Check Endpoint Design
For HTTP health monitors, implement a dedicated/health endpoint in your application:
What a health endpoint should check
What a health endpoint should check
A good health endpoint verifies that all critical dependencies are available:
- Database connection is alive
- Cache layer (Redis, Memcached) is reachable
- Required configuration is loaded
- Application can accept requests (not in restart/initialization state)
What a health endpoint should NOT do
What a health endpoint should NOT do
- Do NOT make the health endpoint expensive (no full DB queries)
- Do NOT require authentication (health probes run without credentials)
- Do NOT check external dependencies not under your control (external APIs, third-party services)
- Do NOT return 200 during graceful shutdown — return 503 to drain traffic before stopping
Next Steps
Pools
Manage the pools that health monitors are attached to.
Troubleshooting
Resolve OFFLINE member status and health probe failures.
Create Load Balancer
Create a complete load balancer setup with health monitoring from scratch.
Listeners
Configure the protocol and ports that route traffic to your pools.