HTTP status code
Gateway Timeout
A gateway did not receive a timely response from an upstream server.
The proxy reached your application and waited, and the application never finished. Unlike a 502, the connection succeeded — the response just took longer than the proxy was prepared to wait. The request may well still be running on the backend.
Find the slow operation rather than raising the timeout — raising it converts a fast failure into a slow one and usually makes things worse under load. Check slow query logs first; a query that was fine at ten thousand rows and is not at ten million is the classic case. Anything genuinely slow belongs in a background job with the request returning immediately.
A 504 usually arrives after your monitoring has already flagged degraded response times. Watching response-time trends gives you warning before requests start timing out outright.
Monitor for 504 responses freeThe backend taking longer to respond than the proxy will wait. In practice that is nearly always a slow database query or a blocking call to an external service.
Rarely. A longer timeout means requests occupy workers for longer, which reduces the number of concurrent users you can serve and can turn a slow endpoint into a full outage. Fix the slow operation, or move it to a background job.
No. In a 502 the proxy got an invalid response or none at all — the app may not be running. In a 504 the app is running and simply too slow. The distinction tells you whether to check process health or query performance.
Pingura checks your endpoints from five regions and alerts on the status code, not just reachability.
Get Started Free