Cloudflare Error 524: A timeout occurred

The TCP (and usually TLS) path to your origin worked. Cloudflare then waited for an HTTP response and gave up. Your app was too slow — or stuck — not unreachable.

What visitors see

Error 524
A timeout occurred
The origin web server took too long to respond.
Cloudflare Ray ID: …

Unlike 521/522, the origin accepted the connection. Something on the origin (or an upstream it calls) did not finish writing a response in time.

524 vs 504 vs 522 vs 521

Enterprise plans can raise Cloudflare’s origin read timeout; on lower plans you usually cannot wait “forever” — redesign slow work instead of hoping the edge will wait.

Frequent real causes

• Slow or blocking request handlers — synchronous PDF export, huge DB report, image crunching, waiting on a third-party API with no deadline.
• DB locks / N+1 queries — the connection stays open while the database crawls.
• Upstream behind the origin — your nginx waits on an app that waits on Redis/S3/another HTTP API; only the outer Cloudflare timer is visible to visitors.
• Missing timeouts inside the app — fetch/HTTP clients without AbortSignal / connect+read deadlines hang until 524.
• Cold starts + long boot — serverless or scale-to-zero that exceeds the read timeout on the first request.
• Websocket / long-poll mistaken for HTTP — long-lived streams need different products/settings; a plain proxied HTTP request will 524.

Diagnose

# Time to first byte straight to origin (grey-cloud or Host + IP):
curl -svo /dev/null -w "connect:%{time_connect} TTFB:%{time_starttransfer} total:%{time_total}\n" \
  --max-time 120 https://ORIGIN_IP/slow-path -H "Host: example.com" -k

# On origin: which worker is stuck?
sudo ss -tnp | head
# app logs / APM around the Ray ID timestamp
# DB: long-running queries, locks

# nginx example — align proxy_read_timeout with reality (do not set infinite):
# proxy_connect_timeout 10s;
# proxy_read_timeout 60s;

If origin TTFB is already >100s, Cloudflare 524 is expected. Fix the handler (async job + poll, streaming, caching, smaller query) before asking for a higher timeout.

Fix checklist

1. Confirm it is 524 not 522 — connect works; response is late.
2. Measure origin TTFB — reproduce with curl; note the slow route.
3. Make work asynchronous — accept 202, queue a job, let the client poll or use a webhook; return quickly from the edge-facing request.
4. Add deadlines — DB statement timeout, HTTP client timeouts, circuit breakers; fail fast instead of holding workers.
5. Cache or precompute — expensive reports generated ahead of time.
6. Align proxy timers — nginx proxy_read_timeout, app server idle timeouts, and Cloudflare’s limit should be intentional; raising everything hides bugs and ties up workers (see 504).
7. Warm critical paths — reduce cold-start impact if scale-to-zero is in play.

# Sketch: do not hold the proxied request for the whole job
POST /exports → 202 { "id": "…" }   # enqueue
GET  /exports/ID → 200 or 404       # poll until ready

Related

All Cloudflare error codes · Cloudflare Error 523 · Cloudflare Error 520 · Cloudflare Error 525 · Cloudflare Error 526 · HTTP 504 Gateway Timeout · Cloudflare Error 522 · Cloudflare Error 521 · 502 Bad Gateway · HTTP 503 · ETIMEDOUT · ECONNRESET · TypeError: Failed to fetch · Anvil HTTP status · Wirebook: when sites get tired

Questions

Published 7 November 2026.