A recurring fatal has a request behind it
PHP fatal errors and memory exhaustion rarely happen at random. Each one was triggered by a specific request, and when the same fatal recurs, the same kind of request is usually behind it.
Finding that request pattern is what turns a wall of fatals into a fixable cause. The error message tells you what failed; the correlation tells you which request made it fail, which is what you actually need.
This article covers how to connect fatals and memory errors back to the requests that caused them, using the logs and traces the store already produces.
The error and the request are in different logs
The challenge is that the fatal and the request are usually recorded separately. A memory exhaustion error lands in the PHP or application log, while the request that triggered it is in the web server access log.
Neither log alone names both the failure and the URL. The fatal says what broke, and the access log says what was requested, and connecting them is the diagnostic step most people skip.
Doing that correlation is what moves the investigation from "we get memory errors" to "we get memory errors on this specific page." The second statement is actionable.
Correlating by timestamp
The simplest correlation is time. A fatal has a timestamp, and the access log has an entry for the request at that same moment.
Line up the fatal's timestamp with the access log, and the request at that moment is your suspect. When the same URL keeps appearing next to the same fatal, you have found the pattern, not just an instance.
The shape of the triggering request
Certain request shapes recur as fatal triggers. Learning to recognize them speeds up the correlation:
- A category page with many layered-navigation filters applied, generating a huge query and result set.
- An API endpoint pulling a large collection without pagination.
- An export or report URL building a big dataset in memory.
- A bot hitting a heavy, uncached URL repeatedly at high frequency.
When the access log shows one of these next to a memory fatal, the pattern usually explains the recurrence. The request is doing more work, or holding more memory, than the limit allows.
Using application performance monitoring
Where the store has application performance monitoring, the correlation is easier. Transaction traces tie an error directly to the endpoint and the code path that produced it, without manual log matching.
A tool that groups errors by transaction shows immediately which endpoint accounts for the fatals. It also shows the memory and time profile of that transaction, which points at what inside it is expensive.
This is the fastest path when it is available. The trace does the correlation the logs make you do by hand, and it adds the code-level detail the logs lack.
The PHP-FPM slow log
The PHP-FPM slow log is a middle ground between the access log and full monitoring. It captures requests that exceed a duration, writing a stack trace for each.
Because memory-heavy requests are often slow requests, the slow log frequently catches the same requests that produce fatals. The stack trace it records names the code the request was running when it was caught, which points at the expensive path.
Enabling and reading the slow log adds a source that ties slow, heavy requests to their code, complementing the access-log timestamp correlation.
From pattern to root cause
Once the request pattern is identified, the root cause is usually close. A category page fataling on many filters points at the layered-navigation query and result size, and an export fataling points at building the dataset in memory.
The fix follows the pattern. Paginate the unbounded collection, precompute the heavy report, index the query behind the slow page, or rate-limit the bot hammering the heavy URL.
The correlation is what makes the fix targeted. Without it, you are raising memory limits blindly; with it, you are fixing the specific request that keeps failing.
Recurrence is the signal to correlate
A one-off fatal may be a fluke. A fatal that recurs is a pattern, and a pattern means a specific request keeps triggering it, which is exactly what correlation finds.
Treat recurrence as the prompt. When the same fatal appears repeatedly, stop reading it as an isolated error and start matching it to the requests around it.
That shift, from reading errors to correlating them with requests, is what turns recurring fatals into a short list of pages and endpoints to fix.
Find the request, fix the cause
Fatals and memory errors are triggered by requests, and recurring ones are triggered by patterns. Correlating the error with the access log, the slow log, or a transaction trace names the request behind it.
Knowing which requests trigger your fatals, and fixing those specific paths rather than raising limits blindly, is how recurring memory problems actually get solved. That correlation work is a core part of a stability review.