Some log errors are not code problems at all
Magento's application logs are full of stack traces, and it is easy to read every one as a code bug. Many of them are not. They are infrastructure problems surfacing through the application.
A dropped database connection, a Redis that refused a connection, a search cluster that timed out: these all land in exception.log looking like application errors, when the real cause is a layer underneath.
This article covers the log signatures that point at infrastructure, what each one usually means, and how reading them correctly saves hours of debugging the wrong thing.
The database has gone away
One of the most common infrastructure signals is "MySQL server has gone away." It looks alarming and is almost always about the connection, not the query.
It usually means the database closed the connection, often from a wait_timeout being exceeded during a long idle period, a query exceeding max_allowed_packet, or the database being restarted. The application was mid-conversation and the connection vanished.
Connection refused to Redis or the search engine
When Magento cannot reach a dependent service, it logs a connection error naming that service. A "connection refused" to the Redis port or the OpenSearch host is infrastructure speaking through the application log.
These mean the service is down, unreachable, or misconfigured, not that the code calling it is wrong. A burst of them usually lines up with the service restarting, running out of memory, or a network issue between the application and the service.
Reading the host and port in the error tells you exactly which dependency failed. That is a server or configuration investigation, not a code review.
Unable to write, and disk problems
Errors about being unable to write a file, create a directory, or open a log point at the filesystem. The two usual causes are a full disk and a permission problem.
A disk that has filled produces a wave of write failures across cache, session, and log operations at once. A permission problem is narrower, affecting only the paths owned incorrectly, but both show up as write errors in the application log.
When write errors appear across many unrelated operations at the same time, check disk space first. It is the single cause that breaks writing everywhere at once.
Memory and resource exhaustion
Memory fatals sometimes reach the application log and sometimes do not, but when they do, they are an infrastructure signal as much as a code one. "Allowed memory size exhausted" points at the PHP limit or an operation too large for it.
A cluster of these tied to a specific job usually means that job outgrew its memory allocation as data grew. That is a capacity and configuration question, alongside any code inefficiency.
Reading these next to server memory metrics separates a genuine leak from a limit that simply needs to match the work. Both are real, and they have different fixes.
Timeouts to external services
Integrations, payment gateways, and shipping providers all log timeout errors when the remote service is slow. These are infrastructure signals about the network and the third party, not about Magento.
A recurring timeout to a specific external host, at a steady rate, usually means that service is degraded or rate-limiting you. The store's code is doing its part; the boundary is where the failure lives.
Correlating these with the provider's status is faster than reading your own code, because the problem is on the other side of the call.
Reading logs for infrastructure, not just bugs
The skill is pattern recognition. Certain signatures reliably mean infrastructure, and learning to spot them redirects the investigation to the right layer immediately.
Group the log by frequency, then ask of the top signatures whether each names a dependency, a connection, a resource, or an external host. Those are infrastructure, and they belong to the server and services investigation rather than the code one.
This is also where the application log and the server metrics belong side by side. A log signature plus a matching spike in a server metric is a confirmed infrastructure cause.
The log is telling you where to look
The application log is more than a record of code failures. Read correctly, it is a diagnostic map that points at the database, the cache, the disk, or an external service when the problem is really there.
Knowing which signatures mean infrastructure, and acting on them at the right layer, is the difference between fixing a problem and rewriting code that was never broken. Reading logs this way is a core skill in any stability or infrastructure review.