Cloudflare Error 524: A Timeout Occurred (125 Second Limit)

Error 524 means Cloudflare connected to your origin successfully, but the origin did not send an HTTP response before the Proxy Read Timeout expired. Cloudflare's documentation gives the default as 125 seconds. The connection worked; the application was too slow, or stuck.

The visitor sees a Cloudflare page headed "A timeout occurred." Because the TCP connection succeeded, firewalls and DNS are usually fine, and the work is in your application. For other codes in the family, see Cloudflare 520-526 errors explained. Note that some older guides quote 100 seconds; use the current number in Cloudflare's docs.

What causes a 524

Per Cloudflare:

• The origin is busy with a large task, such as a big data query or export, or lacks resources to respond in time.
• The origin accepts the request but does not reply within the read timeout.
• Cloudflare connects to write data but the write does not finish within the 30-second Proxy Write Timeout (Cloudflare Images uses 6.5 seconds). The write timeout cannot be adjusted.

Real-world triggers include unindexed database queries, report generation, large imports, a plugin calling a dead third-party API, a deadlocked worker, or a backend queue so long that your request waits for a free worker.

If you are a visitor

Reloading usually repeats the same slow request, so it may fail again. Wait a few minutes. If you triggered a long action (an export or a bulk upload) and see this error, the job may still be running on the server, so check before repeating it. Report persistent failures to the site owner with the Ray ID.

If you are the site owner

Step 1: find the slow request

Log response times on your origin so the slow path is visible. For nginx, add $request_time and $upstream_response_time to a log format:

log_format timed '$remote_addr "$request" $status $request_time $upstream_response_time';
access_log /var/log/nginx/access_timed.log timed;

Then list requests slower than 100 seconds:

awk '$(NF-1) > 100 {print}' /var/log/nginx/access_timed.log | head

Cloudflare's Origin Analytics can also show P95 origin response times and a "Top endpoints" table. If P95 is close to the timeout, the same paths will produce 524s sooner or later.

Step 2: fix the root cause on the origin

Typical fixes, in order of payoff:

1. Database: run the slow query log (slow_query_log=1 in MySQL), then add indexes or rewrite queries.
2. Move long work to a background job. Return immediately with a job ID and let the browser poll for status. Cloudflare recommends polling the status of large HTTP processes rather than waiting on one request.
3. Check external calls. Set sane timeouts on HTTP clients so a dead third-party API does not hang a request for minutes.
4. Check worker capacity. If every PHP-FPM or application worker is busy, new requests queue and exceed the limit. Look at pm.max_children and the PHP-FPM status page.
5. Resource pressure: memory exhaustion or swapping makes everything slow; see reduce time to first byte.

For the web-server side, nginx upstream timed out and fix 504 Gateway Timeout cover the origin timeouts that tend to fire first.

Step 3: take the long task off the proxy path

If a few requests legitimately run longer than 125 seconds, such as a large export, Cloudflare suggests routing them through a subdomain that is DNS-only (grey cloud) so they bypass the proxy. For example, serve export.example.com unproxied. You then lose Cloudflare's protection and caching on that hostname, so authenticate it well and keep it narrow. Another option is a presigned download link from object storage.

Step 4: raise the timeout, if you are on Enterprise

Cloudflare documents that Enterprise customers can raise the timeout up to 6,000 seconds in two ways: a Cache Rule using the Proxy Read Timeout setting (the content must be cacheable for the rule to trigger, though it does not have to be cached), or the zone-wide proxy_read_timeout setting through the API. The docs add that the error may appear about one second after the configured timeout, so setting 126 rather than 125 works around the edge case. Check Cloudflare's current documentation before relying on this, as plan features change.

Step 5: confirm it stays fixed

Re-run the slow action and watch both the origin log and Cloudflare. Use the Website Speed Test for ordinary pages, and add an Uptime Monitor on a representative heavy URL. A monitor that records response time lets you see slowdowns that precede 524s.

Distinguishing 524 from related timeouts

If you see 504 from your own nginx or load balancer before Cloudflare gives up, tune those first; load balancer health checks explains their timeouts.

Next steps

• Identify the code on your domain with the Cloudflare Error Checker.
• Measure response times with the Website Speed Test.
• Read nginx 502 and 504 timeout tuning.
• Run the Website Health Check for a quick overall view.
• Track slow endpoints continuously with an Uptime Monitor.

FAQ

How long is the Cloudflare 524 timeout?

The default Proxy Read Timeout is 125 seconds per Cloudflare's documentation. Enterprise customers can raise it up to 6,000 seconds.

Does a 524 mean the request failed on my server?

Not always. The origin may still be processing the request after Cloudflare gave up, which matters for actions like payments or imports.

Can I fix 524 by caching?

Only for cacheable content. For dynamic work, make the origin faster or move the work to a background job.

Is 524 caused by my visitors' connections?

No. The delay is between Cloudflare and your origin, not between the visitor and Cloudflare.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.