524 A Timeout Occurred (Cloudflare) Fix

Problem

Cloudflare returns Error 524: A timeout occurred. This one is easy to misread as a connectivity problem, but it’s the opposite. Cloudflare’s edge connected to your origin just fine, sent the HTTP request, and then sat waiting for the response. The origin never finished sending it before Cloudflare’s timeout — about 100 seconds on the default plans — elapsed. So the edge gives up and serves the 524 page. The TCP handshake worked. The request was delivered. Your server simply took too long to produce an answer. That points the investigation squarely at the origin’s response time, not at DNS, firewalls, or routing.

Symptoms

• Cloudflare’s branded error page shows Error 524: A timeout occurred.
• The page appears after a long wait — roughly 100 seconds — not instantly (an instant Cloudflare error is usually a 521 or 522, which are connection failures).
• It often hits specific endpoints: a heavy report, a bulk export, a slow search, a webhook that does too much inline. Static pages and light routes load fine.
• It may be intermittent, tracking with load or with the size of the request rather than being constant.

Top 3 Causes

1. A genuinely slow endpoint - The request kicks off work that takes longer than ~100 seconds: an unindexed database query, an on-the-fly PDF or CSV export, a synchronous call to a slow third-party API, image or video processing done inline. The origin will answer — just not before Cloudflare stops waiting.
2. A stuck or starved origin - The application is deadlocked, spinning in a loop, or out of headroom. Exhausted worker processes (PHP-FPM pm.max_children, a full thread pool), a saturated CPU, memory pressure, or a database connection pool that’s fully checked out all mean the response can’t be produced in time even for requests that are normally fast.
3. A long-lived connection that isn’t a normal request - WebSocket-style or long-polling connections that stay open past the edge timeout, or a keep-alive mismatch where the origin closes idle connections Cloudflare expected to reuse. These surface as 524 even though no single “request” is slow in the usual sense.

Diagnose with DechoNet

• HTTP Check against the failing URL to measure how long the origin actually takes to respond and whether it ever completes. A response that trickles in near or past 100 seconds is your smoking gun.
• Port Check on the origin’s 80/443 confirms the connection layer is healthy — which, for a 524, it should be. A clean port result rules out the 521/522 connection failures and keeps the focus on response time.

Resolution Checklist

• Reproduce against the origin directly, bypassing Cloudflare, and time it: curl -o /dev/null -s -w 'total: %{time_total}s\n' --resolve YOUR_DOMAIN:443:ORIGIN_IP https://YOUR_DOMAIN/slow-path. If it takes ~100s+, you’ve confirmed the origin is the bottleneck, not Cloudflare.
• Find the slow work. Check the slow-query log (log_min_duration_statement in Postgres, the slow query log in MySQL), the application’s own request timing, and APM traces for the offending route. The endpoint that 524s is almost always doing one expensive thing synchronously.
• Fix the shape, not just the speed: move long-running work (exports, reports, third-party calls, media processing) to a background job and return immediately with a status/poll endpoint. This is the durable fix — trimming a 130-second query to 95 seconds just moves the cliff.
• For work that legitimately must run long and can’t be refactored now, route that endpoint through a DNS-only (grey-clouded) subdomain so it skips Cloudflare’s proxy and the 100-second cap. Cloudflare documents this as the supported escape hatch.
• Check origin capacity under load: worker/thread limits, DB connection pool size, and CPU/memory headroom. A 524 that only appears at peak is usually starvation, not a single slow query.
• Re-run HTTP Check after the fix and confirm the endpoint now completes well inside the timeout from more than one request.

When to Escalate

• On an Enterprise plan, the edge timeout is adjustable — you can raise the proxy read timeout (up to 6,000 seconds) via a Cache Rule. This is a pressure valve, not a fix: a route that needs a 30-minute HTTP timeout is a route that should be a background job.
• If the origin sits behind your own nginx/HAProxy, confirm which layer times out first. An upstream proxy_read_timeout or fastcgi_read_timeout shorter than the real work will emit a 504 before Cloudflare’s 524 — chase the innermost timeout.
• If you use Cloudflare Tunnel (cloudflared), it has its own connection and idle timeouts independent of the 100-second proxy limit; a 524 through a tunnel points at the tunnel’s config, not just the app.