Cloudflare health checks track the health of pools. They are configured through monitors, which define what type of health check to run and how frequently to run them. Cloudflare monitors your servers from each of our data centers.
Health checks that result in a status change for an origin server are recorded as events in the Load Balancing event logs. You can create, attach, and configure health checks from either the Load Balancing dashboard or the Cloudflare API.
- Availability monitoring checks the health of origin servers every 15 seconds. It reports results via email notifications and the Cloudflare API.
- The default retry rate is 5 retries/second and is completely configurable. We do not recommend increasing the retry rate significantly. Retries use exponential backoff (1, 2, 4, 8, 16 seconds by default).
- You can configure monitoring for specific URLs by sending periodic HTTP requests to the load balancer, taking advantage of customizable intervals, timeouts, and status codes. Once an origin server is marked unhealthy, multi-region failover reroutes traffic to the next available server in failover order.
- Load Balancing monitors use the following HTTP user-agent:
"Mozilla/5.0 (compatible; Cloudflare-Traffic-Manager/1.0; +https://www.cloudflare.com/traffic-manager/; pool-id: $poolid)". The
$poolidcontains the first 16 characters of the Load Balancing pool that is the target of the health check.
- To prevent health checks from failing, and to secure user infrastructure against spoofed checks from bad actors, we recommend the following:
Monitors support a great deal of customization and have the following properties:
|Name ||Description ||Constraints|
Port number to connect to for the health check. Required for TCP checks. HTTP and HTTPS checks should only define the port when using a non-standard port (HTTP: default 80, HTTPS: default 443).
The method to use for the health check. This defaults to 'GET' for HTTP/HTTPS based checks and 'connection_established' for TCP based health checks.
The timeout (in seconds) before marking the health check as failed
The endpoint path to health check against. This parameter is only valid for HTTP and HTTPS monitors.
The interval between each health check. Shorter intervals may improve failover time, but will increase load on the origins as we check from multiple locations.
The number of retries to attempt in case of a timeout before marking the origin as unhealthy. Retries are attempted immediately.
Follow redirects if returned by the origin. This parameter is only valid for HTTP and HTTPS monitors.
(known as Simulate Zone in the UI) pushes a request from Cloudflare Health Monitors through the Cloudflare stack as if it were a real visitor request to help analyze behavior or validate a configuration. It allows you to emulate the specified zone while probing.
A case-insensitive sub-string to look for in the response body. If this string is not found, the origin will be marked as unhealthy. This parameter is only valid for HTTP and HTTPS monitors.
The HTTP request headers to send in the health check. It is recommended you set a Host header by default. The User-Agent header cannot be overridden. This parameter is only valid for HTTP and HTTPS monitors.
Do not validate the certificate when monitor use HTTPS. This parameter is currently only valid for HTTP and HTTPS monitors.
Last modification time
The protocol to use for the health check. Currently supported protocols are 'HTTP','HTTPS' and 'TCP'.
API item identifier tag
The expected HTTP response code or code range of the health check. This parameter is only valid for HTTP and HTTPS monitors.
Managing monitors via the Load Balancing dashboard
Managing monitors via the Cloudflare API
load_balancers/monitors endpoint to manage monitors via the Cloudflare API.
Health check integration with PagerDuty
PagerDuty will generate an email address that will create incidents based on emails sent to that address.
If you already have email integration configured in PagerDuty, you can find the designated email address by going to Configuration > Services > Email (under Integrations).
When creating the Notifier object, configure the email to go to the PagerDuty integration email. Consequently, whenever a pool or origin goes down, an Incident will be created to capture it.