Origin Health Check
Periodic requests to a specific endpoint (usually /health or /ping) to verify the origin is responding correctly. Health checks typically verify HTTP status code (2xx), response time threshold, and optionally response body content.
Full Explanation
Health checks are periodic probes that a CDN sends to your origin server to verify it is alive and responding correctly. The typical approach is an HTTP GET request to a dedicated endpoint like /health or /ping. The CDN checks whether the response comes back with a 2xx status code, within an acceptable response time, and optionally whether the response body contains expected content (like a JSON payload with "status": "ok").
If the health check fails, the CDN can take automatic action. The most common failover strategies are: route traffic to a backup origin, serve stale cached content while the origin is down, or return a custom error page. This happens without any manual intervention, which is the whole point. You want your site to stay up even when your primary origin goes down.
Tuning the check interval and failure threshold matters more than people think. Check every 5 seconds and you detect failures fast, but you are also sending a lot of probe traffic. Check every 60 seconds and you might serve errors for a full minute before failover kicks in. Most setups use 10-30 second intervals with a threshold of 2-3 consecutive failures before marking the origin as unhealthy. This avoids flapping on a single timeout.
# Example CDN health check configuration
health_check:
path: /health
method: GET
interval: 15s
timeout: 5s
healthy_threshold: 2 # 2 consecutive passes to mark healthy
unhealthy_threshold: 3 # 3 consecutive failures to mark unhealthy
expected_status: 200
expected_body: "ok"
failover:
backup_origin: backup.example.com
serve_stale: true
stale_ttl: 3600Your /health endpoint should be lightweight. Do not make it run database queries or call external services unless you actually want to test those dependencies. A simple 200 response that confirms the web server process is running is usually enough. If you need deeper checks, use a separate /readiness endpoint that tests database connectivity and other dependencies.
Examples
A minimal health check endpoint and how to test it:
# Django health check view
from django.http import JsonResponse
def health_check(request):
return JsonResponse({"status": "ok"}, status=200)# Test your health endpoint the way a CDN would
curl -o /dev/null -s -w "status: %{http_code}, time: %{time_total}s\n" \
https://origin.example.com/health
# status: 200, time: 0.043sFrequently Asked Questions
Periodic requests to a specific endpoint (usually /health or /ping) to verify the origin is responding correctly. Health checks typically verify HTTP status code (2xx), response time threshold, and optionally response body content.
A minimal health check endpoint and how to test it:
# Django health check view
from django.http import JsonResponse
def health_check(request):
return JsonResponse({"status": "ok"}, status=200)# Test your health endpoint the way a CDN would
curl -o /dev/null -s -w "status: %{http_code}, time: %{time_total}s\n" \
https://origin.example.com/health
# status: 200, time: 0.043sRelated CDN concepts include:
- Failover — Automatically switching to a backup server, origin, or CDN when the primary one fails. Good …