Every service running on the web server on which your WordPress website is hosted has a log file. Log files are used to keep a record of what a service or software has done or what errors it encountered while running. Hence why logs are a vital tool for administrators, webmasters, developers, testers and anyone who works with software (including WordPress) or maintains an IT system.
Typically, we focus on the WordPress activity logs because that is WP Activity Log does – it keeps a record of everything that happens on your WordPress website and multisite network in an activity log.
Though in this article we introduce you to some useful log files you can find on a typical WordPress web server. Logs give you all the information you need as long as you know what you are looking for and where to look for it, hence why we have written this article. So when managing a WordPress website you might need to refer to some of the below log files to troubleshoot a technical or user problem, learn about possible malicious attacks, and do forensic work.
Web server logs
Starting with the most obvious, the web server log files. WordPress is written in PHP so it is typically hosted on either an Apache or a Nginx web server. WordPress can also be hosted on Microsoft’s IIS web server but it is not so common. So in this section we will focus on the *nix based web servers.
Both the Apache and Nginx web servers have two log files which are of interest to us, the access log (access.log), and the error log (error.log). The logging modules of both web servers are very extensive. The webs servers can be configured to generate more detailed logs and log files, segregate them etc.
Web server access log
The access log is where the web server service keeps a log of all the HTTP requests it has processed. Therefore in it you will find information about the:
- IP address of the device from where the HTTP request originated
- User ID in case user is authenticated via HTTP
- Date and time of when the web server finished processing the request
- Request line (includes the HTTP method, requested object, protocol)
- HTTP response code to that request
- Size of the object sent as a response in bytes
- Other generic information such as the requester’s user-agent string.
You can configure the web server to keep a log of much more information in the access log file, such as the query-string sent by the user. Typically such information is handy if you are troubleshooting a particular user issue. Also, web servers which host multiple websites can have a separate access log for every website.
When do I need to refer to the web server log file?
Before services such as Google Analytics, the web server access log files were used to generate reports on website visitors. Though nowadays they are mostly used for troubleshooting connectivity and access issues.
By analysing the access logs of your web server you can also learn about the type of attacks your website is being subjected to, thus making it easier for you to take the necessary evasive actions to protect your WordPress from those malicious attacks.
Web server error log
In the error log the web server service saves all the diagnostic data it generates during normal operations, for example when starting up or initializing a module. In the same log file the web server also saves the errors it encounters when processing HTTP requests it receives when visitors are browsing, or attacking your WordPress website. So in the error log file you can find information such as:
- Date and time of when the problem happened
- Severity level of the error
- The IP address of the client that generated the error
- The error itself.
When do I need to refer to the web server log file?
The web server error log is the most important log file. It is the log file you first look into if you have problems starting up the web server service, or if the web server encounters problems completing an operation.
In relation to your WordPress work, the web server error log file can provide you with vital information when for example you are troubleshooting a HTTP 500 error, a file permissions problem, or an issue with a plugin that interacts directly with the web server and operating system such as a caching plugin. Some plugins or custom web applications might also send information to the web server error log.
PHP error log file
PHP keeps a record of all the errors that occur when running a web application in a log file. If PHP is running as a module on Apache, most probably the PHP errors will be logged in the web server’s error log file. Though you can configure PHP to keep a log of all errors in a dedicated log file, which might be better if you are running a large setup. If you configure a PHP specific error log file the web server have to have write permissions to write to the log file.
When do I need to refer to the PHP error log file?
The PHP error log file is mostly used by developers when developing a WordPress plugin, theme or some other WordPress customization in PHP. In it they can find a record of all the errors that occurred while the application was being executed, which could help them fix any issues they might have.
As a WordPress user and administrator you might be asked by a plugin developer to refer to it since you might find useful information in it if you are having issues running a particular plugin or theme.
WordPress Debug log file
WordPress has its own debug log file and by default it is disabled. Read how to enable the WordPress debug log file for more information on what type of information you can find in the WordPress debug log file and what are the different logging options available.
When do I need to refer to the WordPress debug log file?
This is another vital log file for WordPress developers. We use it a lot ourselves and ask our plugin users for it when we need to troubleshoot some issue. Though it is also of help for WordPress administrators which can use this log file to find more information about possible plugins or theme issues they are having on their website.
MySQL is the most widely used database server for WordPress websites. By default logging is not enabled on MySQL, though should you need you can enable any of the below log files.
MySQL error log: in this log file you will find diagnostic information about problems encountered when starting, running or stopping the MySQL service. Therefore it does not contain any information related to databases or the data stored in the databases.
General query log: In this log file the database server keeps a log of all the connections and queries (also known as SQL statements) it receives from established client connections. Therefore if you enable it while using WordPress you can see the SQL statements WordPress uses to request or post data to the database.
The MySQL server has several other log files which you can use to troubleshoot issues such as data replication, but from the WordPress troubleshooting point of view, the above should do the job.
When do you need to refer to the MySQL database server logs?
The MySQL server logs are useful for web server administrators, to help them troubleshoot daemon (service) and connectivity issues.
The General query logs are useful for plugin and other developers who are developing a solution that reads and writes data to the WordPress database. We use these log files ourselves in support. For example if a plugin user is searching for something in the WordPress activity log and the results are incorrect, we use this log file to see the exact query that is being sent to the database server.
TIP: Refer to the MySQL logs documentation for more detailed information on how to configure logging on the server.
SMTP Server Logs
The SMTP server role on a web server is to send emails. There are quite a few popular SMTP servers for Linux, such as Postfix, Sendmail and QMail. Every server has its own log files and log formats, so the below explanation is more of a generic guideline. If you want to learn more about the exact log file format and naming convention your SMTP server uses, refer to it’s documentation.
Mail.log log file
In the mail.log file you will find information about all the emails sent by the server. In it you will also find information about the response it got from the remote server. So in the mail.log file you can see the:
- Date & time of when the log entry was written,
- Daemon’s (service) name and process ID,
- The SMTP commands and header information (such as the declaration of the from and to email addresses),
- The status of the email (if it was sent, queued etc).
Below is an abstract from a mail.log log file:
postfix/pickup: CF89B3F0EA: uid=33 from=<www-data>
postfix/cleanup: CF89B3F0EA: message-id=<email@example.com>
postfix/qmgr: CF89B3F0EA: from=<firstname.lastname@example.org>, size=1263, nrcpt=1 (queue active)
postfix/smtp: CF89B3F0EA: to=<email@example.com>, relay=smtp.sendgrid.net[184.108.40.206]:587, delay=0.02, delays=0/0/0.01/0.01, dsn=2.0.0, status=sent (250 Ok: queued as 7M1TBD6xSfGYOu00qaczcA)
postfix/qmgr: CF89B3F0EA: removed
When do I need to refer to the mail.log file?
This log file is handy to troubleshoot email delivery problems and relay issues. For example if a customer has problems receiving the emails you are sending, use the SMTP server log file to find out if it was successfully delivered to their servers or is still queued on your server. You can also find information and troubleshoot relay issues if for example someone reports that spam email is being relayed through your web server’s SMTP server.
SMTP Server error log
Your SMTP server also has an error log file. Different servers use different naming conventions for their log files, but more often than not the name of the SMTP server error log file is mail.err.
In the SMTP server error log file you will find information about any issues the service encountered when starting up, running or stopping. In this error log file you won’t find information about the processing and sending of emails.
When do I need to refer to the SMTP server error log file?
You will only need to refer to this log file if there are issues with the SMTP service. So you will find useful information if the service is failing to start, or authentication is not working etc. As such this is nothing related to WordPress but always good to know about it.
Syslog log file
Syslog is the equivalent of the Windows event log. It is where the operating system and some of the services running on the server keep a log of events and errors that happen during startup, running and stopping. Even though syslog is typically used as a central logging system to which other network attached devices can report to, in this article we will look at it as a single server log.
Format of Syslog messages
Syslog messages are typically human readable, but not always. Every message includes basic information to help you identify which process is reporting it, time, data, severity level and the message itself. There are seven severity levels, which are:
- 0 = emergency
- 1 = alert
- 2 = critical
- 3 = error
- 4 = warning
- 5 = notice
- 6 = information
- 7 = debug
When do I need to refer to the Syslog file?
Most of the operating system events that happen when it is starting up and running are logged in the syslog log file. Also, services that do not have their own log file, such as some firewalls, keep a log of events in the syslog log file as well.
Therefore you might need to refer to the syslog log file if you are troubleshooting an operating system issue, which most probably, and hopefully you won’t encounter much when using the server solely to host a WordPress website.
Other log files you can find on your WordPress web server
The above is an overview of the information you can find in the log files of some of the most common services running on a WordPress web server. You might have several other log files on your web server that might be useful to you. It all depends on your setup and what other services you are running on it, such as a firewall, DNS server, DHCP server etc.
Understanding activity logs and log files to better manage your WordPress website and web server
The same as with a WordPress activity log, log files cannot be passed up when it comes to running and managing a WordPress website, a multisite network, a web server or any other IT system. Log files give you a good insight on what has happened on your server, which is handy when you need to troubleshoot a technical issue, generate a report and try to identify what happened during a malicious hack attack and.
Log files also allow you learn on how a system is being used (or abused in case of malicious attacks) so you can improve it. If it happened, log it! I talk in more detail about this subject in the below webinar, which WP White Security (we) and Sucuri co-hosted: