On this page
Debugging Magento 2 errors: log locations and how to read them
When your Magento store misbehaves, the cause is almost always written in a log file - here is where to look and what to do with what you find.
Magento errors are deliberately vague on screen. Visitors might see a white page, a 500 error, or a generic "An error has occurred" message - none of which tells you anything useful. The real detail - the exact error, the file it happened in, and usually the extension responsible - is recorded in Magento's logs.
Checking them takes two minutes and very often turns a mystery into a known problem with a known fix.
Where Magento keeps its logs
All paths below are relative to your Magento installation directory.
var/log/exception.log- uncaught errors with full stack traces. When something is actually broken, the answer is usually here. Check this file first.var/log/system.log- general warnings, notices and errors from Magento and installed extensions. Noisier thanexception.log, but useful for problems that do not crash the page, such as failing cron jobs or misbehaving integrations.var/log/debug.log- verbose debugging output. This file should not normally exist on a live store. If it is present and growing, debug logging has been left on and should be switched off (see our guide on production mode).- Other files in
var/log/- many extensions write their own logs here, particularly payment gateways and shipping integrations. If you are troubleshooting a specific extension, look for a log file named after it. var/report/- when a visitor is shown an error page with a report ID, that ID corresponds to a file in this directory containing the full error and stack trace. This is the quickest route from "a customer sent us a screenshot" to the actual cause.
Errors that happen before Magento starts - such as a PHP syntax error from a bad deployment or a fatal memory error - never reach Magento's logs. Those appear in the server-level error logs instead, which you can view in cPanel under Metrics > Errors, or in the error_log files within your site's directories.
Reading the logs over SSH
The most useful technique is to watch a log live while you reproduce the problem. Connect via SSH, change to your Magento directory, and run:
tail -f var/log/exception.log
Then trigger the error in your browser. The new entry that appears is your culprit. Press Ctrl+C to stop watching.
To look back at recent entries instead:
tail -n 100 var/log/exception.log
To search a large log for a keyword or date:
grep "2026-06-11" var/log/system.log
grep -i "checkout" var/log/exception.log
How to read what you find
A log entry starts with a timestamp and the error message, followed by a stack trace - the chain of code that was running when things went wrong. You do not need to understand the trace fully to get value from it. Look at the file paths, because they tell you whose code failed:
- Paths containing
vendor/magento/are Magento's own code. The error here is usually a symptom; the cause is further down the trace. - Paths containing
vendor/someothername/point to a third-party extension, and that vendor name tells you which one. - Paths in
app/code/are custom code written for your store.
In practice, the vast majority of Magento errors trace back to a third-party extension or custom code. Identifying the module from the trace means your developer can go straight to the problem rather than starting from scratch.
Patterns worth recognising
SQLSTATEin the message - a database problem, often a missing table or column after an incomplete upgrade. Runningphp bin/magento setup:upgradefixes many of these.Allowed memory size of ... exhausted- PHP ran out of memory. The trace shows what was running at the time. If it happens repeatedly, contact our support team about your PHP memory limit.- The same error repeating at exact intervals - almost certainly a failing cron job. Cron failures are also recorded in the
cron_scheduledatabase table, where thestatusandmessagescolumns show what is failing and why.
What to do with what you find
If the trace points at an extension or custom code, that is developer territory.
The fix involves changing code, which is something the extension vendor or your developer needs to handle. Sending them the full log entry - including the complete stack trace and the time it occurred - will save them significant time.
If the logs point at something server-side, or you are not sure what you are looking at, send us the same information: the exact time, the URL or action that triggers the error, and the relevant log excerpt. We are always happy to help interpret a trace and tell you where the problem lives, even when the fix itself sits with a developer.
Keep debug logging off in production, and keep an eye on log file sizes. On a busy store they grow quickly - we cover managing that in our log retention guide.