Cloudflare Error 524 — A Timeout Occurred — means Cloudflare opened a connection to your origin, sent the request, and waited 100 seconds without receiving a complete HTTP response. Everything about the network worked. Your application simply took too long to answer, and that narrows the investigation to one thing: whatever is slow behind that URL.
What 524 proves, and what it rules out ¶
This is the most diagnostically useful of Cloudflare's 5xx codes, because of how much it eliminates. DNS resolved. The route existed (not a 523). The connection was accepted (not a 521). It did not hang before the handshake (not a 522). Your server is running, listening, and accepting work.
It accepted this particular request and did not finish it in 100 seconds.
The 100-second limit ¶
That number is Cloudflare's proxy read timeout, and on Free, Pro and Business plans it is fixed — you cannot raise it. Enterprise plans can. This matters because the common instinct, "increase the timeout", is usually not available to you, which turns out to be a good thing: an endpoint that needs more than 100 seconds to produce a response is an endpoint with a design problem, not a configuration one.
524 vs 504, and why Cloudflare invented its own code ¶
A standard 504 Gateway Timeout says a gateway gave up waiting for an upstream. 524 says the same thing with an extra claim attached: the origin held the connection open and never sent a response. Cloudflare separates them deliberately, so the error points at your server rather than at their network. In practice the fix is identical — find what is slow — but the code tells you nobody is confused about where the delay is.
What is actually taking 100 seconds ¶
- A slow database query, most often one that was fast until a table grew or an index was dropped. This is the leading cause by a wide margin.
- An external API call in the request path. Your endpoint calls a third party, that third party is having a bad day, and its slowness becomes yours. Any outbound call made while a user waits needs its own timeout, shorter than 100 seconds.
- Long-running work done synchronously — report generation, video processing, bulk imports. These belong in a queue, not in a request.
- Exhausted worker pools. Every worker is busy, your request sits in the accept queue, and the clock runs while it waits. The symptom is 524s appearing under load and vanishing when traffic drops.
- A deadlock or lock contention where the request is genuinely stuck rather than merely slow.
Diagnosing it ¶
- Time the endpoint against the origin directly, bypassing Cloudflare. If it takes 100+ seconds there too, you have reproduced it and Cloudflare is only the messenger. If it is fast, look at load — the problem may only appear under concurrency.
- Check whether it is one endpoint or all of them. A single slow route is an application bug; every route timing out is resource exhaustion or a dependency everything shares, usually the database.
- Correlate with traffic. 524s that track your busiest hours are a capacity story. 524s at constant low volume are a specific broken query.
- Look at what the request was waiting on, not just how long it took. Application traces beat access logs here, because the access log records the total and not the cause.
Fixing it properly ¶
The durable fix is almost always to stop doing the work inside the request. Accept the job, return 202 Accepted with an identifier immediately, do the work in a background queue, and let the client poll or receive a webhook. That converts a request that might time out into one that never can.
Where the work genuinely must happen live, stream. Cloudflare's timeout applies to receiving a complete response, so an endpoint that begins sending data early — headers, then chunks — keeps the connection productive rather than idle. This is why long downloads through Cloudflare do not 524 while a slow JSON endpoint does.
And put timeouts on every outbound call your request makes. A dependency with no timeout is a dependency that can hold your connection until Cloudflare gives up on it.
FAQ ¶
Can I increase the 524 timeout?
Only on Enterprise plans. On Free, Pro and Business the 100-second limit is fixed. Treat that as a constraint worth designing around rather than an obstacle — users abandon long before 100 seconds anyway.
Is 524 my fault or Cloudflare's?
Yours, essentially always. 524 specifically means the connection to your origin worked and your origin did not reply in time. If you want to rule out Cloudflare having a broader incident, check Cloudflare's own status — but a 524 on one endpoint while the rest of the site is fine is not a Cloudflare problem.
Why do only some pages give a 524?
Because only some pages are slow. That pattern is good news: it points directly at the endpoint to profile, rather than at a site-wide capacity problem.
Does a 524 mean my site is down?
Partly. The server is running and serving whatever else is fast, but any visitor hitting the slow path sees an error. Monitoring the homepage alone will report the site as healthy while the endpoint that matters is failing — which is a good argument for monitoring the paths that carry your actual traffic.