How to setup and use WordPress Error log


When you develop the website, it is not a bad idea to control the possible errors or check another information the server replies to your queries. One of the best ways to do that is to setup and read the WordPress logs. In the article, we are going to explain what are the types of log files, how to set it up on different servers and read them to analyze the different aspects of your website.

How to setup WordPress error logs

WordPress error log

There are two main server types: Apache and Nginx. Let’s see how to setup WordPress error log for each of them.

Apache is a powerful open-source solutions for web servers. The logging capabilities in Apache are very flexible. Most log setting options are applicable to any operating system, but some of them are specific only for Unix or Linux.

Apache by default is pretty well configured for logging one’s site. The standard httpd.conf file must have a section of logs with detailed comments for each directive. The default log directory is usually located in /etc/httpd/logs. Now let’s look at the log settings section:

Apache WordPress Error Log

The error log contains messages from Apache like errors, notifications, warnings etc. This log is very useful for finding and fixing server side problems. It is written in site’s Apache config file usually placed in /etc/apache/sites-available/ folder. Let’s see how to setup it:

If you want to store all information about errors in one log, this directive will suffice. However, you can specify an error log file for each domain. This is done in the <VirtualHost> sections approximately as follows:

If you are a system administrator or have root access to the server, you should be able to monitor these logs. We recommend to use one file. And if you provide hosting for clients, it is more convenient to set a separate error log for each client so that they can track their errors.

The level of errors entering the log is set as follows:

Types of Errors

The following error levels are defined in Apache:

  • emerg — emergency – the system does not function;
  • alert — the error must be immediately corrected;
  • crit is a critical error;
  • error;
  • warn — warning;
  • notice — notification (normal operation);
  • info — information message;
  • debug — debug message.

Keep in mind that all subsequent levels include previous ones. That is, if we set the warn level, the log will get errors from the following classes: emerg, alert, crit, error and warn.

Nginx WordPress Error Log

Log files are the first place to look for errors. Especially if it relates to a web server. In Nginx there are only two main logs: error log and access log.

Logging of the Nginx errors occurs in a specific file, stderr, or syslog. It collects all the errors that occurred during the operation of the web server. By default, it is enabled globally:

To log only certain errors, you need to place a directive in the http, server, stream, or location section. And so you can only log critical errors and alarms

Nginx : Types of logs

Error log is very useful when debugging a site issues, configuring new plugins, and installing themes. So, for example, if you see a “White screen of Death” Error when you open your site, the first thing to do is to open an error log for this site in your account. The error log is the most optimal way to monitor and detect errors when working or configuring a site.

The Access log shows the IP addresses and which URL has been accessed, along with a time stamp for each domain. This can be useful for the detection and analysis of third-party log analyzers and for identifying and security issues like DDOS attack.

Next, remember that the logs are included in the total quota of disk space for the account. If you have little space on your server, then you need to periodically clean these logs or turn them off. With the correct operation of the site (without errors) and a small number of visitors, your logs will be small. That’s why you can clean them periodically if there is not enough disk space. But there are cases when the error log or the access log becomes very large. The error log can be large in size if some script does not work correctly and every time it is accessed, an error occurs that is noted in the log — such a log will have many entries and, accordingly, a large size.

The access log can be of a large size if a site is under attack like a DDoS ​​attack.

How to enable WordPress Error logs (Nginx)

In order to enable dedicated and separate Error and Access log for a single site, we need to add the following code in it’s Nginx site config file. This file is usually present in the ‘/etc/nginx/sites-availble/‘ folder.

How to enable logs using wp-config.php

The wp-config file contains basic parameters and settings for your site on WordPress. It stores such important data as: connection settings to the database, a prefix for the database tables and an address for logging into the admin area, if WordPress is installed in a subdirectory.

But in addition to the basic settings, wp-config can also be used to set other parameters. For example, you can enable debugging mode (wp_debug) and write all the received data to the error log. In most cases, this helps to identify and fix problems on the site.

First of all, you need access to the wp-config.php file itself. The file is located in the root directory of WordPress, and in order to edit it, we need an FTP client or File Manager if you have access to cPanel.

Open the file wp-config.php and find there the line “That’s all, stop editing! Happy blogging.”

Just before this line, add a new line of code:

Perhaps this line is already present in the file with the “FALSE” value. In that case, you do not need to duplicate it, just change FALSE to TRUE.

With this code, you will enable the WordPress debug mode. Be ready that WordPress will display all warnings and errors on the site at the top of the page, both in the admin panel and on the site itself.

Therefore, the general recommendation is not to leave debug mode on permanently, use it only when necessary.

Now, in order to additionally include the record of all detected errors and warnings in the log file, add one more line of code in the same wp-config file, just below the line with WP_DEBUG:

How to view WordPress Error logs

From command line

To view the logs from the SSH console or command line, we will use the ‘tail‘ command in this example.

The tail command allows you to view the last 10 lines of the file, in this case the error or access log.

In case you need to see more number of lines, For example 25, then we can use the ‘n’ flag :

Or the following way:

The second useful parameter that you can pass is -f. With this parameter, tail displays the specified number of last lines and continues to read the lines to add, until you press Ctrl+C. It means that you can live-track the changes in the log file. This is particularly helpful when trying to pin point the exact URL which is causing the error. You can reload the page and see exactly which errors it is throwing :

Here a sample output for a tail command

Let’s breakdown one error log entry and see what it means

  • 2018/07/11 03:59:43— Timestamp, when the error occured
  • [error] —Type – Error. This can also be Notice, Warning etc;
  • “PHP Fatal error: Out of memory  ….” — Error message;
  • “” — IP from where the request originated;
  • [07/Aug/2013:23:04:22 +0000] — request date and time;
  • GET /robots.txt HTTP/1.1 — the request;
  • host: “” — The Domain name;

Apache Error Log Example :

The logs includes the domain name to which the request was registered, the time of the request, the IP address from which the access was made and, directly, the error text.

View WordPress Error log using FTP

WordPress error log

If you have a FTP user credential which has sufficient permissions to access the WordPress Error log and access log files, then you can simply login using a FTP Client like FileZilla and then navigate to the Error log Directory and download it or open it directly in an editor of your choice.

The WordPress error log is a great way to control the website processes. How often do you use them?

Leave a Reply

Your email address will not be published. Required fields are marked *