504 Gateway Timeout

Server Error - Upstream server didn't respond in time

HTTP 504 Gateway Timeout

What It Means

The HTTP 504 Gateway Timeout error occurs when a server acting as a gateway or proxy did not receive a timely response from the upstream server. The upstream is alive but too slow.

Request Flow

User → Nginx (proxy) → App Server ⏱️ (too slow) → 504

504 vs 408 vs 502

Code Who timed out
408 Client was too slow sending request
502 Upstream returned invalid response
504 Upstream took too long to respond

Common Causes

  • Slow database queries: Long-running queries blocking responses
  • Heavy computation: Request triggers expensive processing
  • External API slow: Third-party service taking too long
  • Resource contention: Server under heavy load
  • Network issues: Slow connection to upstream
  • Deadlock: Application stuck waiting

Timeout Configuration

Nginx

location / {
    proxy_pass http://app;

    # Connection timeout (establishing connection)
    proxy_connect_timeout 60s;

    # Time to receive response
    proxy_read_timeout 60s;

    # Time to send request
    proxy_send_timeout 60s;
}

AWS ALB / CloudFront

# ALB: idle_timeout.timeout_seconds (default 60)
# CloudFront: Origin response timeout (default 30s, max 60s)

How to Debug

# Check app response time directly
time curl http://localhost:3000/slow-endpoint

# Monitor slow queries
EXPLAIN ANALYZE SELECT ...;

# Check for resource exhaustion
top
iostat
netstat -an | grep ESTABLISHED | wc -l

# Application profiling
console.time('operation');
await heavyOperation();
console.timeEnd('operation');

Solutions

  • Increase timeout: Short-term fix if requests legitimately take long
  • Optimize queries: Add indexes, rewrite slow queries
  • Add caching: Cache expensive computations or API calls
  • Background jobs: Move slow work to async queues
  • Pagination: Return smaller result sets
  • Scale up: Add more servers or resources

Long-Running Request Pattern

// Instead of waiting for slow operation
// Return immediately and poll for result

app.post('/api/reports', async (req, res) => {
  const jobId = await queue.add('generateReport', req.body);
  res.status(202).json({
    status: 'processing',
    jobId,
    checkUrl: `/api/reports/status/${jobId}`
  });
});

app.get('/api/reports/status/:id', async (req, res) => {
  const job = await queue.getJob(req.params.id);
  if (job.isCompleted()) {
    res.json({ status: 'complete', result: job.result });
  } else {
    res.json({ status: 'processing' });
  }
});

Frequently Asked Questions

What does HTTP 504 Gateway Timeout mean?
HTTP 504 Gateway Timeout indicates that a server acting as a gateway or proxy did not receive a timely response from the upstream server. The upstream server is alive but too slow to respond within the proxy's configured timeout period.
What causes 504 Gateway Timeout errors?
Common causes include slow database queries, heavy computation triggered by the request, slow external API calls, resource contention under high load, network issues between the proxy and upstream, and application deadlocks.
How do I fix 504 errors?
For quick fixes, increase proxy timeout values. For proper fixes, optimize slow database queries (add indexes), add caching for expensive operations, move slow work to background jobs, implement pagination for large result sets, and scale your infrastructure.
What is the difference between 504 and 408?
504 means the upstream server was too slow responding to the proxy. 408 means the client was too slow sending the request to the server. 504 is a server-side performance issue; 408 is a client-side network issue.
How do I monitor for timeout issues?
UptimeSignal monitors response times and alerts you when endpoints start timing out or responding slowly. You can set custom timeout thresholds to catch performance degradation before it becomes a full 504 error.

Catch timeouts early

UptimeSignal alerts you instantly when your endpoints start timing out.

Start monitoring free →

Related Status Codes

More Resources