Magento does not record every failure the store has
Teams treat var/log/exception.log as the record of what went wrong. It is not complete, because a whole class of failures happens before or outside the point where Magento can log anything.
A PHP fatal that kills the process, a gateway timeout, a request that never reached PHP: these leave no trace in Magento's own logs. They live in the web server and PHP-FPM logs instead.
This article covers where those failures are recorded, what the common status codes mean, and how to correlate the web server logs with Magento's own to see the full picture.
The logs Magento never writes to
Underneath Magento sit the web server and the PHP process manager, and each keeps its own logs. These capture what the application cannot:
- The web server error log, from nginx or Apache, recording failures at the server layer.
- The web server access log, which records the status code of every request.
- The PHP-FPM error log and slow log, which capture process-level failures and slow requests.
When a customer reports an error that leaves no trace in Magento, these are where the evidence is. Reading only the application log guarantees you miss part of the story.
Reading the access log for 5xx
The access log records a status code for every request, which makes counting server errors trivial. Filtering for the 5xx codes shows what failed and how often.
awk '$9 ~ /^5/ {print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rnThe result is a count of each server error code over the log's window. A cluster of 502s or 504s at a particular time is a concrete lead that no Magento log would have given you.
What the status codes actually mean
Each 5xx code points at a different layer, and knowing which narrows the cause quickly. The common ones tell distinct stories:
- A 500 is an application error, often a PHP fatal that may or may not have reached Magento's log.
- A 502 means the web server could not get a valid response from PHP-FPM, often because workers were exhausted or crashing.
- A 504 is a timeout: PHP took longer than the web server was willing to wait.
- A 499, in nginx, means the client gave up and closed the connection, usually because the backend was too slow.
PHP-FPM worker exhaustion
The most common cause of 502s under load is PHP-FPM running out of workers. The pm.max_children setting caps how many requests can run at once, and when they are all busy, new requests fail at the gateway.
Slow requests make this worse, because each slow request holds a worker longer, and a handful of hung requests can occupy every worker. This is where the payment module with no timeout, or the unbounded query, turns into a site-wide 502.
The PHP-FPM slow log captures these directly, writing a stack trace for any request that exceeds a configured duration. It is the fastest way to see which requests are holding workers open.
Correlating with Magento's logs
The full picture comes from lining up timestamps across the logs. A 500 in the access log at a given second often has a matching stack trace in exception.log, and a 504 often matches a slow-log entry in PHP-FPM.
When a failure appears in the web server log but nowhere in Magento, that itself is the finding: the request died before Magento could handle it, which points at PHP configuration, memory, or the server layer rather than application code.
This correlation is also what a good observability setup automates, so that server-level errors are visible next to application errors instead of in a log nobody reads.
Tuning the timeouts that cause 504s
A 504 is a negotiation between the web server and PHP about how long to wait, and the settings live on both sides. The web server has a read timeout for the backend, and PHP-FPM has its own request termination timeout.
When these are mismatched, requests get cut off in confusing ways. A backend timeout shorter than a legitimate long-running admin task will kill that task with a 504, while a termination timeout that is too generous lets a hung request hold a worker far too long.
The fix is not simply raising every timeout. It is setting them so genuine work completes while truly stuck requests are cut loose quickly, which keeps one slow request from cascading into worker exhaustion and a wave of 502s.
Look where the store actually failed
The failures that damage a store most are often the ones its own logs never recorded. The web server and PHP-FPM logs are where those live, and checking them is not hard once you know they exist.
Knowing your real 5xx rate, and whether it traces to application errors or to worker exhaustion and timeouts, is the difference between guessing and diagnosing. Reading the full log picture is a standard part of any stability or infrastructure review.