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.
"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.
Monitors support a great deal of customization and have the following properties:
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 sub-string must appear within the first 10KiB of your response body.
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.
Use the Create Load Balancer or Edit Load Balancer panels in the Load Balancing dashboard to manage health check monitors. For step-by-step guidance, see Create, attach, and configuring health checks.
load_balancers/monitors endpoint to manage monitors via the Cloudflare API.
The Cloudflare API supports the following commands for monitors. (Examples are given for user-level endpoint but apply to the account-level endpoint as well.) For more detail, see Cloudflare API: Load Balancer Monitors.
To integrate Cloudflare Health Check notifications with PagerDuty, follow the steps outlined in PagerDuty’s Email Integration Guide. If you do not have a PagerDuty account, you will first need to set that up.
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.