Magento 2 Error Logs: Reading and Acting on Them

Magento logs everything and tells you nothing - until you know where to look. The difference between a store that catches problems in minutes and one that hears about them from customers is usually a log-reading routine, not better tooling. Here is the map of Magento’s logs and the practice that makes them useful.

The Core Files

All in var/log/:

• system.log: the general stream - warnings, notices, module chatter. Noisy by default
• exception.log: uncaught exceptions with stack traces. The most important file on the server
• debug.log: only written when developer mode or debug logging is enabled; verbose
• Cron logs: magento.cron.log if your crontab redirects it - first stop for “cron isn’t running”
• Web server logs: Nginx/Apache error logs catch what PHP never sees (timeouts, segfaults, 502s)

When an error page shows a report ID instead of a stack trace (production mode), the trace is in var/report/<id> - a per-incident file. bin/magento errors surface in CLI output directly.

Reading an Exception Efficiently

A Magento stack trace is deep - interception and DI add layers. Read it backwards: the top frames are your code, the bottom is the framework. The first line names the actual error; the first vendor/acme or app/code frame in the trace names where yours broke. Ninety percent of triage is those two lines.

The messages worth pattern-matching:

• Area code is not set - code running outside its area, usually a constructor doing work in a CLI/cron context
• Integrity constraint violation - duplicate writes, often a race or a missing unique-check
• No such entity - stale IDs in queues or caches after data changes
• Class ... does not exist - stale generated code; flush generated/ and recompile

Levels and Volume

Production should log WARNING and above by default; a system.log growing by gigabytes of INFO means a module is logging its life story. When investigating, raise specific channels rather than flipping global debug: monolog handlers in a custom di.xml let you log one module at DEBUG while the rest stays quiet.

Rotation matters: without logrotate, system.log grows until it fills the disk - a real cause of production outages. Rotate daily, keep two weeks, compress the rest.

The Triage Routine

Daily (automated):

grep -c ERROR /var/www/var/log/exception.log   # alert if non-trivially above baseline
tail -200 /var/www/var/log/exception.log | grep -oP 'main\.[A-Z]+: [^\(]+' | sort | uniq -c | sort -rn | head

That count plus a top-errors summary is a morning ritual that catches regressions the day they deploy. Pipe counts into your monitoring and alert on spikes rather than reading raw logs manually.

Weekly: scan for new exception signatures - recurring known noise hides new arrivals unless you diff against last week’s patterns.

The Deeper Habit

Logs tell you what broke; the routine tells you first. Structured alerting on exception.log spikes, a weekly new-signature scan, and rotated, sized log files: that is the whole system. Stores with it are calmer. Stores without it meet their bugs in customer emails.