Load Balancing - Health - Debugging Failure Reasons

Our Load Balancing API adds 'global' health to each Pool and origin server, which gives you a view into what our network sees at a wider level (currently: 70% quorum).

You can optionally get a per-data center breakdown of the health of your origins from our


API endpoint, which will also provide the failure reason: why the health check actually failed.

The possible failure reasons are:

  • "TCP connection failed" - our health checks failed to establish a TCP connection to your origin server. This typically occurs when there is a network failure between Cloudflare and your origin, and/or a firewall refused to allow our connection through
  • "HTTP timeout occured" - the origin failed to return a HTTP response within the timeout configured. If you have this set to a low number - 1 or 2 seconds - we recommend increasing it to allow your origin server to respond.
  • "Response code mismatch error" - we received a HTTP status code that did not match the expected_code of your Monitor configuration. Our health API returns the status in the ResponseCode field; make sure it matches. You may also see this if you have a Monitor configured to use HTTP and your origin server is re-directing to HTTPS; the response code will often be a 301, 302 or 303 instead. Either change your Monitor configuration to use HTTPS, or enable "follow_redirects" to allow us to resolve the correct status code.
  • "Response body mismatch error" - the response body returned from your origin server did not include the (case-insensitive) expected_body configured in your Monitor. Note that we only read the first 10KB of the response: if you return a larger response and the expected_body is not in the first 10KB, the health check will fail.
  • "TLS untrusted certificate error" - the certificate is not trusted by a public Certificate Authority (CA). If you're using a self-signed certificate, we recommend either using a publicly-trusted certificate, or setting "allow_insecure" on your Monitor to "true".
  • "TLS name mismatch error" - our health check (client) was not able to match a name on the server certificate to the Hostname of the request. Check that any Host header set in the Monitor is correct.
  • "TLS protocol error" - ensure that your server supports TLS 1.0 or greater, and is configured for HTTPS.
  • "TLS unrecognized name error" - the server did not recognize the name provided by the client. When a Host header is set, we set this as the ServerName in the initial TLS handshake. If not set, we will not provide a ServerName, which can cause this error. Set the Host header in your Monitor object.



Still not finding what you need?

The CloudFlare team is here to help. 95% of questions can be answered using the search tool, but if you can’t find what you need, submit a support request.

Powered by Zendesk