524 A Timeout Occurred

Cloudflare’s current documentation puts the default Proxy Read Timeout at 125 seconds; older articles still quote 100. A 524 can also come from the 30-second Proxy Write Timeout, when Cloudflare cannot finish sending the request body to the origin, and that one is not adjustable.

The timeout stops Cloudflare from waiting, not your server from working. The origin usually keeps running the request and logs a normal 200 (or a 499 in nginx when it notices the closed connection), so the job may complete even though the visitor saw an error. That is why blind retries of non-idempotent requests after a 524 are risky.

Enterprise zones can raise the limit up to 6,000 seconds, zone-wide through the proxy_read_timeout setting or per path with a Cache Rule. Everyone else has to make the request faster, move it off the proxied hostname, or turn it into a background job.

If you are visiting the site

• The page or action you requested takes the site’s server too long to produce. Submitting it again may repeat the action, such as an order or an upload.

If you run the server

• Endpoints that do heavy work inline: CSV or PDF exports, bulk imports, report queries, calls to slow third-party APIs.
• A slow or locked database query that holds the request past 125 seconds.
• An overloaded origin where requests wait in the queue for a worker.
• Large uploads to a slow origin hitting the 30-second write timeout.

If you are visiting the site

• Before retrying a purchase or form, check whether it went through (an email, your account history). For plain pages, reload later.

If you run the server

• Find the slow endpoints: log request duration at the origin, or use Origin Analytics and look at P95 response times close to the timeout.
• Move long jobs to a queue: return 202 Accepted with a job ID immediately, and let the client poll a status URL or receive a webhook.
• Serve long-running endpoints from a DNS-only (grey cloud) hostname, as Cloudflare suggests, so its proxy timeout does not apply.
• Optimize the underlying work: indexes for slow queries, pagination for exports, timeouts on third-party calls.
• On Enterprise, raise proxy_read_timeout for the zone or per path with a Cache Rule.

Cloudflare generates this code at its edge when it cannot get a usable answer from your origin; your server never sends it. The commands below talk to the origin directly, skipping Cloudflare, so you can see what Cloudflare sees.

# How long does the origin take on its own? (bypasses Cloudflare)
curl -s -o /dev/null --resolve example.com:443:ORIGIN_IP \
  -w 'connect: %{time_connect}s  first byte: %{time_starttransfer}s  total: %{time_total}s\n' \
  https://example.com/reports/export

# nginx on the origin: requests that ran longer than 125 s
awk '$NF+0 > 125' /var/log/nginx/access.log   # with $request_time as the last field

524 vs 504

If a reverse proxy on your origin times out first (nginx proxy_read_timeout defaults to 60 s), visitors get that proxy’s 504 passed through; 524 appears only when Cloudflare’s own 125-second wait runs out.

524 vs 522

522 is a failure to connect; 524 means the connection worked and the response was too slow.

524 vs 499

A 524 at Cloudflare often shows up as a 499 in the origin’s nginx log, because Cloudflare hangs up on nginx at the same moment.

What is Cloudflare’s timeout for error 524?

The default Proxy Read Timeout is 125 seconds according to Cloudflare’s current docs. There is also a fixed 30-second Proxy Write Timeout for sending data to the origin.

Can I increase the 524 timeout?

Only on Enterprise, up to 6,000 seconds, zone-wide via the proxy_read_timeout setting or per path with a Cache Rule. On other plans, make the request faster, use a background job, or serve that path from a DNS-only hostname.

Did my request still run after a 524?

Probably. Cloudflare stopped waiting, but the origin usually keeps processing. Check server logs or the resulting data before retrying anything that creates or charges.

How do I avoid 524 on long exports?

Start the export in a background worker, return 202 Accepted with a job ID, and let the client poll for a download link. The HTTP request then takes milliseconds regardless of the export size.