Cloudflare error 524 means the connection to your origin server succeeded, but your origin did not return an HTTP response before the timeout expired. The default limit is 125 seconds, and only Enterprise zones can raise it.
A 524 error is generated at Cloudflare’s edge rather than by your application, so the page the visitor sees is Cloudflare’s, not yours. It only appears on a proxied record, because a DNS-only record has no proxy in the path to run a clock. The full name on the error page is error 524: a timeout occurred, and “Cloudflare 524”, “CF error 524” and “524 timeout error” all describe this same single code — one Cloudflare defines for itself, since 524 is not a status code in the HTTP standard.
What separates it from every other 52x code is the part that worked. Cloudflare reached your server, your server accepted the connection, and then nothing came back. That narrows the problem enormously: firewalls, IP allowlists, DNS records and encryption modes are all doing their jobs, or you would be looking at a different number. What is slow is the work your application does after it receives the request.
Connected, then silent
Cloudflare documents error 524 as the origin failing to provide an HTTP response before the Proxy Read Timeout. The wording matters: the timer runs on the response, after the request has been acknowledged. The origin acknowledges the request, holds the connection open, and then spends longer than the limit doing whatever the request asked for — a large data query, a report build, an export.
There is a second, much less well known way to produce the same code. If Cloudflare connects in order to write data to your origin and the write does not complete within the 30-second Proxy Write Timeout, that is also a 524. For Cloudflare Images the write budget is 6.5 seconds. Neither of those can be adjusted on any plan, which is worth knowing if you are staring at a 524 that arrived far too quickly to be the 125-second one — a slow upload endpoint is the usual culprit.
125 seconds, not 100
The number most third-party articles give for this error is 100 seconds. Cloudflare’s current connection limits reference puts the default Proxy Read Timeout at 125 seconds. If you have been sizing your own application timeouts against 100, they are in the wrong place. Here is the full set of deadlines on the Cloudflare-to-origin hop, and which code each one produces:
| Limit | Default | Error | Adjustable |
|---|---|---|---|
| Complete TCP connection | 19 s | 522 | No |
| TCP ACK timeout | 90 s | 522 | No |
| TCP keep-alive interval | 30 s | 520 | No |
| Proxy idle timeout | 900 s | 520 | No |
| Proxy read timeout | 125 s | 524 | Enterprise only |
| Proxy write timeout | 30 s | 524 | No |
Enterprise zones can raise the read timeout as far as 6,000 seconds, by two routes. If the content is cacheable, a cache rule carrying the Proxy Read Timeout setting will do it — Cloudflare notes the content has to be cacheable for the rule to trigger, though it does not have to actually be cached. Otherwise the zone-wide value can be set through the zone settings API. One quirk to expect if you do: Cloudflare warns that the error may fire about a second earlier than the value you configured, an artefact of its Pingora proxy, and suggests simply setting the limit one second higher than you need.
What to do when you cannot raise the limit
On Free, Pro and Business the timeout is fixed, so every real fix is about making the request finish sooner or removing it from the proxy path. Cloudflare’s own suggestions, in the order that tends to pay off:
- Stop waiting synchronously. Cloudflare recommends implementing status polling for large HTTP processes: return a job ID immediately, do the work in the background, and let the client poll for completion. This is the only fix that scales, and it also removes a request that was going to fail for slow mobile clients regardless of Cloudflare.
- Move the long jobs off the proxy. For requests that genuinely need more than 125 seconds — nightly exports, bulk reports — Cloudflare suggests putting them behind a DNS-only subdomain. Traffic to a grey-clouded hostname never enters the proxy, so no read timeout applies. Note the trade-off: that hostname exposes your origin address and loses the WAF, caching and analytics that come with proxying.
- Find out why the origin is slow.Cloudflare’s guidance for escalation splits the cause in two: a single long-running process, or a server so loaded it cannot answer anything in time. Those need opposite fixes, and your origin’s own response-time logging is what tells them apart.
- Keep the connection alive while you work. Cloudflare’s notes on 1xx informational responses say that sending interim
102 Processingresponses helps prevent a 524 by keeping the connection active during long processing. It is a stopgap, not an architecture, but it can buy a slow endpoint room while you rewrite it.
Catching it before users do
Cloudflare now points at Origin Analytics for this: it charts origin response time at the 50th, 95th and 99th percentiles against a reference line for your configured timeout. When P95 creeps toward the limit, the Top endpoints table names the slow paths before they start returning errors.
One detail there is easy to misread. The clock in Origin Analytics starts when Cloudflare decides a request must go to the origin and stops when it receives the response headers, so it includes DNS resolution, the TCP and TLS handshakes and the transfer itself. That is deliberately the same round trip the read timeout measures — which is why these numbers run higher than the server-side timings in Grafana or Datadog, and why a service that looks comfortably fast in your own dashboards can still be spending 125 seconds from Cloudflare’s point of view.
When it looks like a 524 but is not
Two neighbours get confused with this one. A 522 is the same silence one step earlier — Cloudflare never got a connection open, usually because a firewall is dropping its IP ranges. A 520 comes from the keep-alive and idle timers rather than the response timer, and shows up as an origin connection that died rather than one that stalled. If you are timing the failure with a stopwatch: roughly 20 seconds is a 522, a minute and a half or more is a 524, and a fast failure on an upload path is the write-timeout flavour of 524 described above.
The useful summary is that error code 524 is not really a Cloudflare problem to solve. Every other 52x number points at something between the visitor and your application; this one points squarely at the application itself, which is why the fixes are all yours.
FAQ
What does Cloudflare error 524 mean?
It means Cloudflare opened a connection to your origin server successfully but never received an HTTP response from it in time. The connection was fine; the application behind it was too slow to answer.
Is the Cloudflare 524 timeout 100 seconds or 125 seconds?
The current documented default for the Proxy Read Timeout is 125 seconds. The 100-second figure is out of date, and it is the single most common inaccuracy in third-party write-ups about this error.
How do I fix error 524 on a free Cloudflare plan?
You cannot raise the timeout below Enterprise, so the fix is to stop the request from taking that long. Cloudflare suggests polling the status of large HTTP processes instead of waiting on them, and moving jobs that legitimately run past the limit onto a DNS-only subdomain that bypasses the proxy.
What is the difference between Cloudflare error 522 and 524?
A 522 means Cloudflare could not establish the connection to your origin at all. A 524 means it established one and then waited without getting a response. Roughly, 522 is a network or firewall problem and 524 is an application performance problem.
Can a 524 error happen in under 125 seconds?
Yes. A second deadline produces the same code: if Cloudflare cannot finish writing the request to your origin within the 30-second Proxy Write Timeout, that is also a 524, and that timeout cannot be adjusted on any plan.