524 means Cloudflare connected to your origin, but the response took over 100 seconds (free/pro plans). Your app really is too slow for the proxy's patience — cache, fix, or move long jobs to background work.
Free/Pro plans cap at 100s. Slow DB queries, N+1s, or synchronous report generation regularly cross it. Time it yourself: curl -w '%{time_total}' against the origin.
Worker starvation, lock contention, or swap-death. The pattern: fast endpoints also degrade around the same time. Check load and slow query logs.
curl -o /dev/null -s -w 'total: %{time_total}s\n' https://origin-host/heavy-endpoint# enable slow-query log (MySQL long_query_time=1 / Postgres pg_stat_statements) + app-level timing around DB/HTTP calls# POST returns 202 + job id; client polls or gets a webhook. Long exports/reports must not occupy an HTTP request for minutes.# Cache Rules / a page rule for the endpoint (short TTL beats computing), or Cloudflare Workers cache API for sub-request level caching# origin_response_timeout (Enterprise). On lower plans the answer is always: get under 100s or make it async.524s leave the origin still running the request — users retry, the pile-up multiplies. Shed load early (queue + 202) instead. A slow endpoint behind Cloudflare also wrecks TTFB for everything else on that origin under concurrency — fixing it helps site-wide.
No — it's fixed on Free/Pro/Business. Enterprise can raise origin_response_timeout. On other plans the fix is architectural: async jobs, caching, or making the endpoint faster.
The origin finished after Cloudflare's 100s window. Cloudflare already answered the client with 524; your 200 went nowhere. That's the signal to go async or optimize below 100s.
Our most-documented failures, packaged as ready-to-ship starter kits: Docker, Kubernetes, and Terraform.
Browse the template store →One-time. Yours to modify. Instant download from the NinjaOps template store.
One short email when new fixes and production templates drop. No spam, unsubscribe anytime.