504 Gateway Timeout

DIRECT ANSWER

A 504 Gateway Timeout means a proxy, CDN, load balancer, or gateway waited for a backend response but its timeout expired first. The backend may still be running; common causes include slow database queries, overloaded workers, long-running tasks, delayed third-party services, and restrictive intermediary timeouts. Compare direct backend timing with the full gateway path before changing timeout settings.

Key takeaways

A 504 usually means the upstream response took too long, not that the backend was immediately unreachable.
If only reports, imports, exports, or complex searches fail, investigate that operation and its database work first.
A longer proxy timeout is appropriate only for a known, healthy operation that legitimately needs more time.
Background jobs are generally better than keeping a browser request open for large or slow tasks.
Comparing direct backend timing with timing through the proxy, CDN, or load balancer helps identify the failing layer.

Updated 2026-09-24 · Editorial review pending HTTP & Server Errors

Site Administrator

What this error means & how to recognize it

The browser shows 504 Gateway Timeout after waiting instead of failing immediately.
Reports, bulk imports, exports, image processing, or complex searches fail while simple pages continue to work.
Failures become more common when the application is busy or requests are queued.
The backend responds when tested directly, but the same request times out through a proxy, CDN, or load balancer.
Gateway logs show an upstream request lasting a long time before the 504 is returned.
The application may continue processing after the browser has received the timeout, potentially leaving duplicate or abandoned work if the action is retried.

Root causes, ordered by likelihood

Slow or blocked database queries: Missing indexes, growing tables, inefficient queries, and lock contention can keep the application waiting beyond the gateway limit.
Backend overload or queueing: Requests may be waiting for application workers, database connections, CPU, memory, or other constrained resources.
A genuinely long synchronous operation: Large exports, imports, reports, or file processing may be valid but unsuitable for a normal page request.
A slow downstream API or webhook: The application may be waiting for another service before it can respond.
Restrictive proxy or server timeouts: Nginx, Apache, a CDN, or a load balancer may stop waiting before the application finishes.
Network problems between gateway layers: Latency, intermittent packet loss, or routing faults are more plausible in multi-server or multi-region deployments, especially when application timing does not explain the delay.

How to fix it

Diagnostic flow at a glance — full detail in the steps below.

1. Identify the failing request and its duration

Check gateway and application access logs for the request that produced the 504. Record the route or user action, timestamp, response duration, status, and whether all requests fail or only one operation does.

If only reports, imports, exports, or complex searches fail, start with that operation rather than treating the incident as a complete server outage.

2. Compare the backend with the complete request path

With authorization and a safe test request, compare the backend’s direct response time with the same request through the proxy, CDN, or load balancer.

A slow response both directly and through the gateway points toward the application, database, capacity, or a dependency.
A fast direct response but a failing proxied request points toward an intermediary timeout, routing problem, or gateway-to-backend network issue.

Do not bypass production access controls or send a state-changing request merely for testing.

3. Investigate database timing and lock waits

Enable or inspect the database’s slow-query and lock-wait diagnostics according to your database platform’s operational guidance. Look for queries running near or beyond the active gateway timeout.

Check for missing indexes, inefficient joins or filters, table growth, and lock contention. Optimize the query, reduce the data processed, or add an index only after confirming that it addresses the measured bottleneck. Coordinate schema or index changes with the database owner because they can consume resources and affect concurrent workloads.

Do not increase the timeout simply to conceal a query that should complete quickly.

4. Check backend capacity and queues

Review application, web-server, and system metrics for worker exhaustion, queued requests, database connection limits, CPU or memory pressure, and other resource constraints during the failure.

If requests are waiting for capacity, address that bottleneck before extending timeouts. Changing capacity or process settings can affect service stability, so make those changes under the applicable operational authorization and change process.

5. Move long-running work to a background job

For imports, exports, report generation, email processing, and similar tasks, use a background job when the application supports it. The initial request should start or enqueue the work, while a separate status view or notification reports progress and completion.

This avoids holding a browser connection, gateway worker, and application request open for the entire operation. Ensure the job has appropriate retry and duplicate-submission handling before enabling this pattern.

6. Review Nginx timeout settings carefully

If Nginx is the gateway, review the applicable proxy_read_timeout and proxy_connect_timeout settings in the relevant server or location block. Confirm which layer is enforcing the timeout before changing anything.

Increase a timeout only when the operation is expected to take longer, the backend is healthy, and the added connection and worker usage is acceptable. Configuration changes require appropriate authorization. After saving the change, validate the configuration and reload Nginx according to your normal deployment procedure, then repeat the previously failing operation. Do not combine a service reload with read-only diagnostics in an unplanned change.

7. Review Apache proxy settings

For Apache using mod_proxy, review the applicable Timeout and ProxyTimeout settings. If large uploads are involved, also review the relevant mod_reqtimeout behavior.

Apply the narrowest safe change for the affected route or operation where possible, with authorization and a rollback plan. Retest using the same request and confirm that longer waits are not exhausting workers or connections.

8. Check CDN and load-balancer behavior

If the site uses Cloudflare or another CDN or load balancer, review that service’s gateway timeout, origin routing, health, and plan-level configuration. An intermediary may enforce a limit that cannot be raised in the available configuration.

When the origin needs longer than that limit, optimize the operation or move it to asynchronous processing rather than relying on a longer browser request.

9. Isolate slow third-party calls

Measure each external API or webhook call separately. Set a shorter internal timeout for a dependency where supported, handle failure explicitly, and return a pending or retryable state when the work can finish later.

Avoid allowing an unreliable dependency to consume the entire gateway timeout. Confirm that retries are bounded and safe before adding automatic retry behavior.

10. Verify the fix

Repeat the exact page action or request that previously failed. Confirm that it completes within the active gateway timeout and inspect logs afterward to ensure the backend is not accumulating abandoned, duplicate, or unusually long-running work. Test through the complete production path, not only against the backend directly.

Prevention & how to verify the fix

Use background jobs for imports, exports, report generation, email processing, and other work that can outlast a normal page request.
Review indexes and query plans for database operations behind frequently timing-out pages as data grows.
Monitor request duration, queue time, database time, worker usage, and dependency time separately.
Set proxy and application timeouts deliberately for the slowest legitimate operation, while keeping third-party dependency timeouts bounded.
Test critical operations through the complete production path, including the CDN or load balancer, rather than only against the origin.
Design retries and repeated submissions safely so a gateway timeout does not create duplicate jobs or transactions.
After a change, repeat the exact operation that timed out and confirm that it completes without accumulating excess queued work.

When to get outside help

Escalate to the CDN, load-balancer, hosting, or network provider when the backend responds quickly in an authorized direct test but the 504 persists through the intermediary, or when the intermediary’s timeout cannot be changed in your configuration.

Involve the application or database team when logs show slow queries, lock waits, exhausted workers, connection-pool limits, resource pressure, or a slow dependency. Provide the failing route or operation, timestamps and time zone, request duration, gateway and application log entries, relevant database timings, and whether direct-backend testing succeeds. Avoid sharing credentials, tokens, or sensitive request data in the escalation.

Run a website check

Frequently asked questions

Is a 504 Gateway Timeout caused by my browser?

Usually not. A 504 is returned by a gateway or proxy that waited too long for an upstream response. You can retry or test another connection if only one session is affected, but gateway and application timing logs are more useful than clearing browser data.

Is the backend server down when a 504 appears?

Not necessarily. It may be running but too slow, overloaded, blocked on a database query, or waiting for another service. An authorized direct test and the application logs can help distinguish a slow backend from a gateway or network problem.

Should I increase the Nginx or Apache timeout?

Only when the operation is legitimately expected to take longer and the backend is otherwise healthy. First investigate slow queries, queueing, worker limits, and third-party calls. A larger timeout can consume workers and connections for longer while merely postponing the same failure.

Why do reports or exports time out while normal pages work?

Reports and exports often process more database rows, generate files, or wait on additional services. Normal pages can remain fast while one heavy request exceeds the gateway limit. Optimize the operation or run it as a background job instead of keeping the page request open.

Can a CDN cause a 504 when the origin works directly?

Yes. A CDN or load balancer can enforce its own gateway timeout or have a routing problem. If the origin finishes quickly but the proxied request fails, review the intermediary’s timeout and origin-path behavior. Some limits may not be configurable for your account or plan.

What should I check if a third-party API causes the 504?

Measure that dependency separately, set a bounded internal timeout, and handle failure without holding the whole request open. For work that can finish later, return a pending status and process it asynchronously. Ensure retries cannot submit the same transaction more than once.

Further documentation

For authoritative configuration details, consult the documentation for the gateway or reverse proxy in use, the web server, the CDN or load balancer, and the application’s database and job-processing components. Pay particular attention to upstream response timeouts, connection timeouts, proxy behavior, request queues, dependency timeouts, and asynchronous job guidance.