HTTP 504 in Vercel

A serverless function exceeded the max duration (10s on Hobby, 60s on Pro, 900s on Enterprise) or the edge middleware timed out (25s hard cap).

Why Vercel returns 504

A serverless function exceeded the max duration (10s on Hobby, 60s on Pro, 900s on Enterprise) or the edge middleware timed out (25s hard cap).

How to fix it

Move long tasks to a queue (Vercel Queues, Inngest, QStash), stream the response, or upgrade the function's `maxDuration` in `vercel.json`.

What it looks like in the logs

[GET] /api/report status=504 FUNCTION_INVOCATION_TIMEOUT

Where this surfaces in Vercel

Vercel's Edge Network, serverless function logs, or the deployment dashboard.

Vercel — serverless deployment platform for Next.js and edge apps.

What HTTP 504 means generally

A proxy or gateway server didn't receive a response from the upstream server in time — the "slow backend" failure mode that's different from 502 (broken backend).

HTTP 504 Gateway Timeout fires when a proxy server (Nginx, Cloudflare, an AWS ALB) successfully connects to the upstream application server, sends the request, and then waits — but the upstream takes too long to send a response back, exceeding the proxy's configured timeout. The TCP connection is fine; the application is just being slow. This is fundamentally different from 502 Bad Gateway (where the connection itself fails) and from 503 Service Unavailable (where the server deliberately says "not now"). 504 is almost always a performance problem in the backend: a slow database query, a long-running API call, an unindexed loop, or a downstream dependency that's itself slow.

Other common causes of 504

• Slow database query — missing index, full table scan, lock contention
• Synchronous call to a slow third-party API (Stripe, SendGrid, OpenAI) without a tight timeout
• Long-running PDF generation, image processing, or report export on the request path
• Proxy timeout configured too aggressively (Nginx default proxy_read_timeout is 60s)
• Origin server overloaded — has the connection, can't process it in time

SEO impact

Persistent 504s damage SEO in two ways simultaneously. First, Google deindexes pages that consistently fail to respond — same as any 5xx error. Second, even when the page eventually responds, the slow response time hurts Core Web Vitals (specifically LCP — Largest Contentful Paint), which is a confirmed ranking factor. A 504 that intermittently resolves into a 6-second 200 is still a ranking problem. Fix the backend slowness, don't just bump the proxy timeout.

How to catch it next time

LemWatch tracks response times alongside status codes — so we can alert you when response times approach your gateway timeout threshold (e.g. >50s on a 60s timeout) before they cross over and start producing 504s. We also distinguish between 504 (proxy timeout) and 524 (Cloudflare timeout) so you know which layer is failing.