Configuring CDN health checks to detect origin failures means you’re essentially setting up a detective to watch your origin server and sound the alarm if it starts acting suspiciously.
Let’s see this in action with a concrete example. Imagine you’re using Cloudflare and want to ensure your origin server, origin.example.com, is responsive.
{
"zone_id": "your_zone_id",
"type": "CNAME",
"name": "cdn.example.com",
"content": "origin.example.com",
"proxied": true,
"ttl": 300,
"origin_monitoring": {
"enabled": true,
"interval_minutes": 1,
"timeout_seconds": 5,
"method": "GET",
"path": "/healthz",
"expected_status_codes": [200]
}
}
This configuration tells Cloudflare to periodically check origin.example.com by making a GET request to /healthz every minute. If it doesn’t get a 200 OK response within 5 seconds, it flags the origin as unhealthy.
The core problem this solves is preventing your CDN from serving stale or error pages when your origin server is down or misbehaving. Without health checks, users might hit the CDN, the CDN would try to fetch content from your origin, fail silently, and then serve a cached error, or worse, an outdated version of a page. Health checks allow the CDN to intelligently route traffic away from unhealthy origins, either to a backup origin or by serving cached content if available and configured to do so.
Internally, the CDN edge servers are performing these checks. They maintain a score or status for each configured origin. When a health check fails, the origin’s score increases. If the score reaches a certain threshold, the origin is marked as unhealthy. Traffic is then rerouted based on your failover configuration. The interval_minutes dictates how often the checks run, timeout_seconds sets the responsiveness window, method and path define the specific request the CDN makes, and expected_status_codes are the acceptable responses that indicate health.
When an origin is deemed unhealthy, the CDN will stop sending new requests to it. If you have multiple origins configured for load balancing or failover, the CDN will automatically direct traffic to the remaining healthy origins. If all origins for a particular hostname become unhealthy, the CDN will typically serve cached content if available, or return an error to the user. The critical lever you control here is defining what "healthy" looks like for your origin – the specific path, expected response code, and acceptable latency.
Most people understand that health checks ping an origin, but they often overlook how the CDN interprets those pings. The CDN doesn’t just care if the server is up; it cares if the server is serving correct responses within an acceptable timeframe. A server that’s technically running but returning 500 Internal Server Error or taking 30 seconds to respond to a /healthz request is effectively down from a user’s perspective, and the health check configuration needs to reflect that by checking for specific successful status codes and setting reasonable timeouts.
The next step is to configure sophisticated health checks that can detect application-level issues, not just network reachability.