Error guide

524 A Timeout Occurred

Cloudflare connected to your origin and sent the request, and the origin took longer than 125 seconds to respond.

524 means Cloudflare connected to your origin, sent the request, and then waited longer than its Proxy Read Timeout for a response. That timeout is 125 seconds by default. Nothing failed at the network level: the connection opened and the request was accepted, and the origin simply did not answer in time.

It is a slowness error, not a reachability one, and the pattern of which requests hit it is the first clue. One slow endpoint, a report, an export or an import, usually means too much work is being done inside a single request. Every endpoint slowing down at once points at a saturated server or a dependency it is waiting on.

On an Enterprise plan the timeout can be raised, up to 6,000 seconds. On every other plan 125 seconds stands, and even where it can be raised, the fix that survives growth is to move long work out of the request: start a background job, return its id straight away, and let the client poll for the result.

Common causes

  • A report, export or import that does all its work inside one request.
  • A slow or unindexed database query holding the response.
  • A call to an upstream API that hangs and has no timeout of its own.
  • An overloaded origin queueing requests faster than it can serve them.
  • Origin timeouts set longer than Cloudflare's, so nothing on your side gives up first.

How to diagnose it

  1. Sort the origin's access logs by response time and check whether one endpoint is slow or all of them are.
  2. Time the same request against the origin directly, bypassing Cloudflare.
  3. Check the database's slow query log and whether the connection pool is exhausted.
  4. Look for upstream calls made without a timeout.
  5. Check the host's load, worker count and request queue at the times of the errors.

Whose fault is it? The server's side

Origin-side. Cloudflare waited 125 seconds for your origin to answer and it did not. The fix is making the request faster or moving the work out of the request, rarely a Cloudflare setting.

What monitoring sees

An Uptimely check gives up before Cloudflare does. Its request timeout is 30 seconds by default and 60 at most, so against an endpoint slow enough to cause a 524 the check times out on its own budget and records a timeout, not a 524. Because the connection to Cloudflare's edge completed, that timeout counts as a failed check rather than being set aside as a network problem. A response-time criterion on the monitor flags the slowdown earlier still, while requests are slow but still finishing.

Questions

How long does Cloudflare wait before a 524?

125 seconds by default. Enterprise plans can raise it, up to 6,000 seconds; on other plans it cannot be changed, so a request that needs longer has to finish some other way.

How do I fix a 524 for a long-running request?

Move the work out of the request. Start it as a background job, return a job id at once, and have the client poll a status endpoint. For a request that genuinely must stay open, serve it from a hostname that is not proxied through Cloudflare.

One of the Uptimely HTTP and network error guides, written for the person who operates the server rather than the one refreshing the page. Something here read wrong to you? Email support@getuptimely.com.