Cloudflare 524 timeout explained

What 524 means

Cloudflare 524 "A timeout occurred" appears when the edge establishes a TCP connection to the origin, forwards the request, but the origin does not send back an HTTP response within Cloudflare's request timeout. The origin acknowledged the connection, it just never finished an answer in time.

The error page shows "524" to the visitor while the origin is left processing a request it might still complete a moment later. Long-running work such as a CSV export, a video transcode, or a big report that exceeds the timeout is the classic trigger.

The timeout window

Cloudflare waits a fixed window for the origin's response. Cloudflare documents this as the Proxy Read Timeout, around 120 to 125 seconds depending on the page.

| Plan | Proxy Read Timeout |

| Free / Pro / Business | Fixed, not adjustable (about 125 seconds by default) |

| Enterprise | Configurable up to 6,000 seconds via zone settings |

The window applies from request to first response bytes, so a slow stream that keeps sending bytes does not hit 524, but a request that sits silently does. Note that the timeout is a property of the Cloudflare edge, not of the origin's PHP or proxy settings, so changing origin timeouts alone does not extend it.

Common causes

• The origin is genuinely slow: a heavy database query, a long-running script, or a PHP worker that ignores execution limits.
• The origin waits on an external service, an upstream API, or a slow dependency.
• Cloudflare's timeout is lower than the origin's own PHP max_execution_time, so the origin thinks the job is still running.
• The origin is under severe load, so requests queue behind other requests.
• Streaming or chunked responses stall: if the origin stops writing bytes, the idle window eventually trips the 524.

Fix slow responses

1. Confirm the request genuinely takes longer than the limit. Test from the terminal against the origin:

curl -w "\nfor total %{time_total}\n" -o /dev/null "https://origin.example.com/big-job"

1. Reduce the work per request. Move heavy work to a background job queue and return a lightweight status page, instead of rendering the whole report synchronously.
2. Set the origin side max_execution_time only if the task must complete truly synchronously. PHP example:

ini_set('max_execution_time', 140);

Then retest, but be honest: raising the origin ceiling does not extend Cloudflare's timeout, it only moves the failure line.

1. Increase efficiency instead. Add a database index, cache the slow query result, or rewrite a paginated stream with a partial response and refresh rather than one long render.
2. If the work is unavoidable, the supported move is to serve only the long job from a non-proxied subdomain (grey cloud), so the origin answers directly and the browser waits as long as needed.
3. For ongoing exports, use a background worker that returns a "processing" response and then the final result asynchronously.

Prevention

• Keep an eye on slow requests: use Origin Analytics in the dashboard to spot P95 response times approaching the timeout before they surface as 524.
• Split large work into chunks, each well under the window, so the total work still finishes.
• Cache the outcome of slow pages with a cache rule only when output is safe to reuse, otherwise the 524 reappears on every cache miss.
• Do not rely on an underpowered origin for long reports; the requests either hit 524 or degrade every other page behind them.

When to get a professional

If the request only times out for some regions or only peaks at certain hours, involve your host or a website engineer early. A network path change or an origin firewall that drops packets partway can masquerade as 524, and that is not fixed by tuning application timeouts.