The most frustrating errors are the ones that vanish the moment you start looking. A visitor reports a 502 Bad Gateway, you reload the page and everything works. An hour later it happens again, to someone else. Intermittent 502 and 503 errors are hard precisely because they're sporadic, and they rarely reproduce on demand. Here we cover what causes them and how to catch a fault you can't trigger yourself.
What 502 and 503 actually mean
Both codes usually come from a web server or load balancer sitting in front of your application. A 502 Bad Gateway means the front server passed a request along but got an invalid response, or none, back from the upstream service, such as PHP. A 503 Service Unavailable means the service temporarily can't handle the request, often due to overload or an ongoing restart. In both cases it's usually the layer behind the web server that's faltering, not the web server itself.
Common causes
- PHP-FPM saturation. If all PHP-FPM workers are busy, new requests queue up and eventually time out, giving 502 or 503. This happens during traffic spikes or when individual calls are abnormally slow.
- Upstream timeouts. The web server only waits a set number of seconds for PHP. A slow database query or a hanging external API can make the web server give up and respond 502.
- Memory exhaustion. When processes hit the memory ceiling they get killed by the system, and in-flight requests are cut off mid-way.
- Restarts and deployments. During a restart of PHP-FPM or the web server there's a brief window where requests can be rejected, producing temporary 502/503.
Why they're so hard to catch by hand
An intermittent error appears maybe a few times an hour, often only under load, and is gone before you can open a terminal. When you test manually, the odds you happen to hit the exact second it occurs are slim. On top of that, the error often only affects a subset of visitors, so your own experience tells you "everything works". Without continuous measurement you only see scattered complaints with no pattern.
Check server and PHP logs
Logs are your best source of truth because they capture the error in the moment. Look at:
- Web server error logs (nginx or Apache) for lines about "upstream timed out", "connection refused" or "no live upstreams" with exact timestamps.
- The PHP-FPM log for warnings about "server reached max_children", a clear sign of worker starvation.
- The PHP error log and WordPress
debug.logfor fatal errors and memory errors at the same times. - The system log (for example
dmesg) for the OOM killer terminating processes due to memory exhaustion.
The key is to correlate the timestamps. If a 502 in the web server log occurs exactly when PHP-FPM reports max_children, you've found the pattern.
Quick first actions
While you dig through the logs, a few actions often ease the symptoms and provide clues at the same time:
- Carefully raise the number of PHP-FPM workers if the server has memory to spare, and see if the errors drop. If they do, it points to saturation.
- Increase the upstream timeout slightly. If the 502s disappear, the cause was slow responses, not crashes.
- Watch memory usage during a traffic peak. A clear ceiling reached just before the errors is a strong sign of memory exhaustion.
Be careful not to simply mask the problem. Raising timeouts can hide a slow database query that really should be optimized. These actions are meant to confirm the cause, not replace a real fix.
How to make the invisible visible with Ravnsight
What you lack when troubleshooting by hand is continuity and history. Ravnsight runs checks minute by minute from multiple geographic locations, around the clock. When an intermittent 502 or 503 strikes, we catch it while it's happening, with a full breakdown of the response time, so you can see whether DNS, connection, TLS or waiting on the server was what broke. Because we confirm a failed check from a second location before alerting, you know the failure is real. Above all, the history gives you the pattern: you see the errors cluster at traffic peaks or that they started right after a deployment. We say correlated, not that we definitively know the cause, but it points you straight at the right log and the right window in time.
