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.
  • "No route to host" -  the IP address cannot be reached from our network. Common causes are ISP or hosting provider network issues (e.g. BGP level), or that the IP does not exist.



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