Skip to content
Load Balancing
Visit Load Balancing on GitHub
Set theme to dark (⇧+D)



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.

Important notes

  • 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; +; pool-id: $poolid)". The $poolid contains 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:
    • Only accept connections to hosts listed in the Cloudflare IP ranges in your firewall or web-server.
    • Use Cloudflare's user agent (see above) to reject HTTP requests that don't come from these ranges.
    • Ensure that your firewall or web server does not block or rate limit Cloudflare health checks.


Monitors support a great deal of customization and have the following properties:

Name /typeDescription /exampleConstraints

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).

  • default value: 0

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.

  • default value: GET

The timeout (in seconds) before marking the health check as failed

  • default value: 5

The endpoint path to health check against. This parameter is only valid for HTTP and HTTPS monitors.

  • default value: /

The interval (in seconds) between each health check. Shorter intervals may improve failover time, but will increase load on the origins as we check from multiple locations.

  • default value: 60
  • minimum values:
    • 60 (Pro)
    • 10 (Business)
    • 5 (Enterprise)

The number of retries to attempt in case of a timeout before marking the origin as unhealthy. Retries are attempted immediately.

  • default value: 2

Follow redirects if returned by the origin. This parameter is only valid for HTTP and HTTPS monitors.

  • default value: false
  • valid values: (true,false)

(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.

{  "Host": [    ""  ],  "X-App-ID": [    "abc123"  ]}

Do not validate the certificate when monitor use HTTPS. This parameter is currently only valid for HTTP and HTTPS monitors.

  • default value: false
  • valid values: (true,false)
string (date-time)

Last modification time

  • read only
string (date-time)

Creation time

  • read only

The protocol to use for the health check. Currently supported protocols are 'HTTP','HTTPS' and 'TCP'.

  • default value: http

API item identifier tag

  • max length: 32
  • read only

Object description

"Login page monitor"

    The expected HTTP response code or code range of the health check. This parameter is only valid for HTTP and HTTPS monitors.

    • default value: 200

    Override HTTP Host headers

    When your application needs specialized routing (CNAME setup or custom hosts like Heroku), change the Host header used in health checks.

    You can set these headers on a specific origin or a monitor. Headers set on an origin override headers set on a monitor.

    Host header prioritization

    When a load balancer runs health checks, headers set on an origin override headers set on a monitor.

    For example, you might have a load balancer for with the following setup:

    • Origin Pools:

      • Pool 1:

        • Origin 1 (Host header set to
        • Origin 2
      • Pool 2:

        • Origin 3
        • Origin 4 (Host header set to
    • Monitor (Host header set to

    In this scenario, health checks for Origin 1 would use, health checks for Origin 4 would use, and all other health checks would default to For more information on updating your custom host configuration to be compatible with Cloudflare, see Configure Cloudflare and Heroku over HTTPS.

    For a list of origins that override a monitor's Host header:

    1. On a monitor, select Edit.
    2. Select Advanced health check settings.
    3. If you have origin overrides, you will see Origin host header overrides.

    List of origin host header overrides

    Managing monitors via the Load Balancing dashboard

    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.

    Managing monitors via the Cloudflare API

    Use the 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.

    Create MonitorPOSTuser/load_balancers/monitors
    Delete MonitorDELETEuser/load_balancers/monitors
    List MonitorsGETuser/load_balancers/monitors
    Monitor DetailsGETuser/load_balancers/monitors/:identifier
    Update MonitorPUTuser/load_balancers/monitors

    Health check integration with PagerDuty

    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).

    monitors 1

    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.

    monitors 2