Cloudflare Error 524: A Timeout Occurred

A 524 means Cloudflare connected to your origin server just fine, sent the request, and then waited. And waited. Your server didn't send back an HTTP response before Cloudflare's Proxy Read Timeout expired. This is a slowness problem, not a connectivity one.

Whose fault is it

The slow response is your origin's doing. Cloudflare's role is enforcing the timeout: it set a ceiling on how long it'll wait, your server blew past it, and Cloudflare cut the connection and returned the 524.

The 524 timeout, precisely

Cloudflare's default Proxy Read Timeout is 120 seconds. The origin must begin sending an HTTP response within that window after the connection is established. Note this is the time to first byte of the response, not the time to finish; a slow trickle that starts in time won't 524, but a request that produces nothing for 120 seconds will.

There's a second, separate limit worth knowing: a 30-second Proxy Write Timeout for Cloudflare writing the request body to your origin (6.5 seconds for Cloudflare Images). That one isn't adjustable. Most 524s are read-timeout cases, but a 524 on a large upload can be the write timeout instead.

On Free and Pro plans the 120-second read timeout is fixed; you can't lower or raise it. Enterprise zones can extend it up to 6,000 seconds, and there's a Cache Rule workaround for cacheable content. For everyone else, the answer is to make the request faster, not to wait longer.

The common causes, most likely first

1. A long-running database query The classic 524. An unindexed query, a full table scan, or a report aggregation that takes minutes. The page hangs waiting for the database, Cloudflare's clock runs out. Check your slow query log and add indexes or rewrite the query.
2. A slow or hanging external API call Your code calls a third-party API that's slow or unresponsive, and your request blocks waiting for it. If that upstream takes 130 seconds, your response can't beat the 120-second limit. Add aggressive timeouts to your outbound HTTP calls so a slow dependency fails fast instead of hanging your whole response.
3. A heavy synchronous task in the request path Generating a large PDF, processing an upload, running an export, or any CPU-bound work done inline during the request. These belong in a background worker, not in the request that a visitor (and Cloudflare) is waiting on.
4. Resource exhaustion or a deadlock The server is starved for CPU, memory, or I/O, so even normally-fast requests crawl. Or the application is deadlocked, waiting on a lock that never releases. Both stall the response indefinitely. Check resource usage and application logs around the error timestamps.

How to fix it properly

The wrong instinct is to find a way to extend the timeout. On Free and Pro you can't, and even where you can, a 120-second page load is a terrible experience. The right fix is to stop making the visitor wait synchronously.

1. Profile the slow endpoint. Use your framework's profiler or Cloudflare's Origin Analytics to find requests with response times near the timeout. The Top Endpoints table points you at the offenders.
2. Optimize the obvious slow paths first: add database indexes, cache expensive computations, set tight timeouts on outbound API calls.
3. For genuinely long work, move it off the request path. Return an immediate 202 Accepted with a task ID, run the job in a background queue (Celery, Sidekiq, BullMQ, SQS), and have the client poll a status endpoint or receive a webhook when it's done.
4. If you run unavoidable long requests like big data exports, move them behind a subdomain that's DNS-only in Cloudflare (grey cloud, not proxied), so the 524 timeout doesn't apply to that path.

How a 524 differs from a 522

They look similar and get confused constantly. A 522 means the TCP connection itself never established; Cloudflare couldn't even reach your server. A 524 means the connection established fine and Cloudflare sent the request, but your server didn't respond in time. A 522 is a connectivity problem (firewall, overload, DNS); a 524 is a slowness problem (queries, slow code). The fix paths are completely different, so the exact code matters.