Magento Error Log: A Definite Guide

Even if you're not a developer, a technical specialist, or a support expert, working with Magento requires certain knowledge both about the CMS itself and some basic things about how web apps work.

Magento error log is a tool that lets you do basic troubleshooting and understand the essence of your issues especially when you see that something is going wrong, but you have no idea what exactly is not OK.

What is more, there can be cases when the apps write error logs without actually doing their job, which causes speed issues and gigabytes of error log files.  You need to use an error log to maintain your site and keep it healthy and issue-free.

Keep reading, and I'll guide you through retrieving this useful information. It might look a bit technical, but believe me or not, it is quite easy.

General error logs concept

Let me start from the very beginning and take a look at how a Magento website operates on the Internet:

You probably know that when a customer requests any website pages, the request is handled by several apps:  first of all, it's a web server, which communicates with the Magento PHP application.  Magento in its turn sends queries to the database. Sometimes, during this process, things can go the wrong way.  Then the responsible app writes the error and corresponding information into a special file called an error log. Monitoring these log files might help you to discover and fix possible issues you may not be aware of for a long time. 

Which error logs should we check? From the picture above you understand that in some cases, like a missing page or image, we need the web-server logs; and for the Magento system errors, like an invalid block type, we need to check the Magento error logs.

This article is focused on the Magento application, so we’ll skip the database and web-server logs review (we will still show an example in the tech section later) and cut to the chase, to the Magento error log. In the next paragraphs, we’ll enable logging, find the log file, understand its structure, and look through examples of some real-life errors. Moreover, there will be a very handy tip that will save you a lot of time at the end of the article, so stay tuned!

Enable error logging in Magento

First off, we need to tell the platform to save error logs for us to carry out Magento audit of the log.  Fortunately, in Magento 2.x error logging is enabled by default, no special configuration is needed. In Magento 1.x it is hidden under Admin > System > Configuration > Advanced > Developer section:

Find the errors log file in Magento

OK, we have the logging enabled and now it is time to find the log files. So what's the Magento log location? For Magento 1.x website they are located in the <magento-folder>/var/log/ folder. If you see no files here please make sure the folder has enough writing permissions, so the web server can create and modify files inside. Our primary files are system.log with all PHP warnings and issues with XML files and exception.log with all the exceptional cases when Magento fails to handle data for some reason.

Magento 2.x uses a slightly different approach. It splits errors by severity according to the Syslog Protocol into files like info.log, debug.log, system.log, etc. For more information, please see this page.

Magento log file structure

If we open the log file, we can find a bunch of lines like this:

16:02:21: 2021-03-13T15:12:23+00:00 ERR (3): Warning: key_exists() expects parameter 2 to be array, null given  in /public_html /app/code/community/TIG/MyParcel2021/Model/Api/MyParcel.php on line 752

The pattern is quite straightforward. It is date tag - 16:02:21: 2021-03-13T15:12:23+00:00, followed by the error level - ERR (3): Warning, error description “key_exists() expects …” and the affected file MyParcel.php plus line 752.  What does it mean? It means the module fails to calculate the delivery cost for some data combinations and it’s time to (warning! explicit advertising here! ) switch to some well-tested shipping solutions.

Here's another example.

2021-03-13T15:17:24+00:00 DEBUG (7): Security problem: newsletter/subscribe has not been whitelisted.

This one reports issues with displaying a “subscribe to newsletter” block. Everything went fine, and then you updated Magento to 1.9.3 but were not aware of the new security feature. As a result, you have hidden CMS blocks and lost subscribers.

One more example from the Magento 2.x error log:

[2020-04-07 17:39:30] main.CRITICAL: exception 'Magento\Framework\Exception\LocalizedException' with message 'The element 'product.info.options' already has a child with alias 'default'' in /var/www/html/ /vendor/magento/framework/Data/Structure.php:611

The same, we have the date, the error level (critical) the error message, and the location.  Here I assume something is wrong with the product view page and its info block.

If you have some errors in the log and do not know what they mean, then feel free to post them as comments, maybe we can sort them out together. Also, it's a good idea to google the text of the error.

I want to stress the following point: while being a store owner, not a developer, you don’t have to understand these messages in and out. It is more important to see there is an issue and to understand that the issue should be fixed.

Displaying Magento error messages

But what if you are a developer and you are working on a theme or a module?  Then everything flips around and often it makes sense to display errors, not just log them in the file.  This way you'll see the errors straight away, without looking into the error log files.

To do this in Magento 1, you can turn on the developer mode environmental variable in the .htaccess file like this

SetEnv MAGE_IS_DEVELOPER_MODE “1”

In Magento 2, please compile the whole Magento application in the developer mode.

php bin/magento deploy:mode:set developer

Read more about the Magento 2 modes here.

Finding Apache error log

Every developer eventually comes to the situation where he or she sees a blank page and there's nothing in the Magento error logs.  It means the error had occurred even before Magento was launched.  Such types of errors are called fatal errors. I’ve put it in the developer section as I have a sheer belief it could happen on the dev server only.  In this particular case, it is worth checking the Apache error logs.  They have no fixed locations, but you can run phpinfo() command to see the path.  The following settings should be set in PHP.INI, virtual host, or .htaccess file.

error_reporting = E_ALL | E_STRICT

log_errors = On

error_log = /var/log/php_errors.log

Here's a very simple example of the fatal error:

Fatal error: Class 'Mage_Compiler_Helper_Data' not found in /var/www/app/Mage.php on line 547

It means a required file is missing.

How to write in the Magento log file

This article is about reading and understanding logs, however, I feel compelled to show how to write something to the logs. It is useful when you debug an application with no frontend part, like cron tasks, or API calls, or whatever.

In Magento 1, all you need to do is to call the static Mage::log() method, like this:

Mage::log($var);

Or:

Mage::log(“value: ” . print_r($var, 1), “mylogfile.txt”);

You can find the full function signature in the app/Mage.php class:

public static function log($message, $level = null, $file = '', $forceLog = false)

The approach has been changed in M2 significantly. Magento 2 complies with the PSR-3 standard. As a default implementation of logger, it uses Monolog. While the logging itself looks like $this->logger->debug(“some message”); a lot of additional logic is involved. See link 1 and link 2 for more details.

Getting notifications about Magento errors

And here is the useful tip I promised to present to you. If the site is up and running, and there are no errors in the logs, then you can easily set up a cron job to send you a message if the files are not empty (and then remove the file).

0 23 * * * /usr/lib/sendmail [email protected] < /home/website.com/www/var/log/exception.log;

rm /home/website.com/www/var/log/exception.log

You will receive a message each time there's a new record in your Magento error log.

This is a simple to-start solution, but I do recommend going further and using any kind of tool to receive Magento error reports.

Conclusion

To wrap it up, I’d like to list the main points of the article:

1. In the production mode all errors are hidden, if not - stop reading and disable them;
2. During a page request an error may arise at a different level;
3. Fatal errors are handled by the web server, not Magento logger, so see Apache logs as well;
4. Exceptions are stored in /logs/ and in the /report/ folders, different for M1 and M2;
5. All other errors are in logs if logs are enabled;
6. It’s easy to set up instant notifications about exceptional cases at your site.

If you need to go global with your store performance analysis, take a look at the Advanced Reports extension.

I hope you will watch out for hidden errors and keep your logs empty, and your Magento site - healthy and maintained.