How to view web server logs in Plesk

If you’ve ever used cPanel before, you’ll surely be skeptical of your control panel’s capability to provide useful logs, however Plesk’s log viewer not only has access and error logs readily available, its functionality has also only improved with each new Plesk version. No need to enable it, or view raw log files: it’s always there when you need it.

When would you want to view the logs?

• When you get a web server error (e.g.: 403, 404, 501, or 502) when visting a webpage or file that should be working, and you want to see a more detailed error log entry
• You want to monitor visitors and/or requests to your website in real time, and optionally want to see which requests require PHP processing.
• When saving a setting or page, you get an error or the page never loads

How to view and monitor logs in Plesk

1. Log in to Plesk
2. If not already there, click on “Websites and Domains”
3. Look for the domain for which you wish to view the logs and select the “Logs” button.

The latest log entries will appear at the bottom. If it’s been a minute or longer since the error occurred on the site the error may not appear on this screen because loading other pages, asynchronous requests, other visitors, and even bots crawling the site will generate log entries.

You can click the “Real Time” button in the upper left to see new entries appended to the bottom as visitors are accessing your site, or you can click the refresh button to manually trigger an update.

Filtering/Searching logs in Plesk

In the upper right corner you can filter which logs you’re seeing by clicking the arrow beside “All Logs”.

For example, if you’re trying to troubleshoot an error, then you want to avoid seeing ‘access’ entries and only see errors, so check off only those that have the word ‘error’ in them.

There is an option to filter by error code (ex: error 502) however it doesn’t always work consistently, so while you can try it out, we don’t recommend relying purely on the results it provides.

There are two great ways to find the right log entries: Time stamp matching and Manual trigger matching. We recommend Manual trigger matching as it’s the most conclusive way to ensure the error you find directly matches the issue.

Time stamp matching

If you attempted to login to your site 5 minutes ago and it presented an error, scroll up in the list of log entries and keep loading earlier results until you’ve reached all entries occurring around that time. You should find the correct log entry there.

Tip: keep an eye out for timezone differences! The bottom of the log represents the most recent entries and should roughly match your current time. So if the most recent log entry says 10:31 am and your clock shows 11:31am, you’ll need to adjust by an hour when searching for specific log entries.

Manual trigger matching

Manual trigger matching best ensures that the errors you’re seeing match with the actions that are causing the problem. You can do this by enabling real-time updates and, in another tab or window, reproduce the problem that generates the error.

Within seconds of reproducing the error, you will see the log entries that correspond in the Plesk log viewer. If you have a lot of traffic, you can filter the log results by your IP address to help narrow things down a bit.

If you’re not seeing the logging you expect

First try disabling any filters you applied (like to only see error logs) because sometimes log entries you have filtered out (yes, even access logs) can provide clues as to the reason for the error.

If that doesn’t do the trick, you may need to enable debug mode in your application. Here’s how to do so with common web apps:

• Enabling debug mode in WordPress
• Enabling debug mode in Joomla
• Enabling debug mode in Magento

If you enabled debug mode in your web app, don’t forget to disable it after you’ve found and resolved your issue otherwise your site will likely use more CPU (IO load) and the debug log files will likely take up much more space on the account.

Searching for the error description

Once you’ve identified the correct log entries you’ll then need to troubleshoot that issue. Since you now have a more specific error description from the logs, your searches should return more accurate results.

• If you’re seeing PHP errors, and you’re using WordPress, our guide to analyzing critical errors with WordPress will help resolve it. Even if you’re not using WordPress, much of that guide will still help you analyze and resolve PHP errors
• Here’s how to troubleshoot 403 forbidden errors.
• Here’s how to troubleshoot Gateway errors like 502.
• Solving 500 errors is here.

If none of the above guides cover your error, try entering your error in our knowledgebase search to find a solution.

If you don’t find your error in our knowledgebase, you can always try a quick Google search for it, or create a support ticket and include the log entry there – please be sure to only include the relevant log entries and only include the first of duplicate entries – and we’ll point you in the right direction.

Benign Log Entries

These are examples of log entries that are safe to ignore:

map files & favicon.ico

2019-04-24 18:37:23 Error 1.1.1.1 404 GET /wp-content/plugins/bbpowerpack/assets/js/swiper.min.js.map HTTP/1.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.103 Safari/537.36 76.3 K Apache SSL/TLS access
2019-04-24 18:37:23 Error 1.1.1.1 404 GET /wp-content/plugins/contentstudio-plugin-master/_inc/main.css.map HTTP/1.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.103 Safari/537.36 76.3 K Apache SSL/TLS access

These are safe to ignore because they are .map files which are not essential to the operation of your website and instead are used to help debug when using minified files. If you’re curious, this article describes what map files are used for.

If you see entries similar to those above, but which indicate a file called favicon.ico or apple touch icon, those are also safe to ignore.

warnings

PHP warnings are good to pay attention to only when you’ve run out of all other options. If you’ve got other troubleshooting info to go on, definitely start with that first. Here’s what a PHP warning will look like in the logs:

2019-04-24 18:37:11 Warning 1.1.1.1 AH01071: Got error 'PHP message: PHP Warning: A non-numeric value encountered in /var/www/vhosts/<domain>/httpdocs/wp-content/plugins/bbpowerpack/modules/pp-logos-grid/includes/frontend.js.php on line 35', referer: / Apache error

Filtering for Dynamic Requests

If you have enabled nginx processing of static files as is recommended for live sites (details in our WordPress performance optimization guide), then nginx will be handling all static file requests including WordPress caches. That means that you can select to view *only* the apache access logs and the output of those will all be dynamic requests.

In the upper right corner of the Plesk Log viewer click the arrow beside “All Logs” and select only the apache access logs.

Filtering for Dynamic Requests via CLI…

If you’ve got your own Plesk VPS with root access to the server filesystem, you can get a bit more power when filtering the logs by logging in using SSH. You’ll find the Plesk log locations here:

/var/www/vhosts/system/<domain>/logs/

You can cd to the logs directory, then use a command like this one to only see the requests that hit apache which are most likely to spawn PHP processes:

cd /var/www/vhosts/system/<put_your_domain_here>/logs/
tail -f access*log

This one filters the results even further:

cd /var/www/vhosts/system/<put_your_domain_here>/logs/
tail -f access*log | egrep " 404 |\/\?|.php" | egrep -v "fbclid"

This command shows you all 404s, any requests that use query parameters, and any request for a .php file.

The last part egrep -v "fbclid" excludes the Facebook tracking URL parameter which, when used, should return cached results safely. You may add additional excludes in there with the | operator, like this: fbclid|anotherclid

It’s important to understand that:

1. Not all requests with query parameters (containing /?) will be dynamic, but we include them here in case at least one of them does.
2. You can remove the 404 entry from the command if you have implemented the .htaccess optimizations for 404s described in our speed optimization guide Bonus Tip #2. The command would then look like this: tail -f /path/to/access/logs | egrep "\/\?|.php"