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
- 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
- Log in to Plesk
- Under “Websites and Domains”, look for the domain for which you wish to view the logs and select its “Logs” button.
- The latest log entries will appear at the bottom.
- 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 update the logs showing.
DEBUG MODE: If you’re not seeing the logging you expect, you may need to enable debug mode in your application. Here’s how to do so with common web apps:
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.
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.
Filtering by error code: If, when visiting the page you’re having trouble with, you get an error 502, look for the text box at the top of the list that says “Code” and enter “502”. When the log listing refreshes, you should now be seeing only those log entries that resulted in a 502 error code.
Filtering by error code may not be helpful in all cases. Sometimes error logging occurs in multiple log entries and only the first of two or more useful log entries explicitly includes the error code.
Match log entries to actions
There’s two ways to analyze these logs for errors. The simplest way to ensure that the errors you’re seeing match with the actions that are causing the problem is to enable real-time updates and, in another tab or window, reproduce the problem that generates the error. You will immediately see the log entries that correspond in the Plesk log viewer.
Alternatively, you can attempt to Match Time Codes. As an example, if you attempted to login to your site 5 minutes ago and it presented a 403 error, take a look at the timestamps in the logs from 5 minutes ago and see what log entries match up.
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.
Search the more specific error
Once you’ve identified the correct log entries which match the action you’re taking where you’ve encountered a problem, you’ll then need to troubleshoot that issue. Since you now have a more specific error to look into than before, your searches should return more accurate results.
- Here’s how to troubleshoot 403 forbidden errors.
- Here’s how to troubleshoot Gateway errors like 502.
- Solving 500 errors is here.
You can then use these more descriptive errors by searching our knowledgebase to find a solution. If you can’t find a solution with a search for the provided error text, you can also create a support ticket and include the log entry there (please be sure to only include the latest entry, if it repeats) and we’ll point you in the right direction.
Filtering for only Dynamic Requests
If you have enabled nginx processing of static files as is recommended for live sites (details in our 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 should all be dynamic requests.
In the upper right corner click the arrow beside “All Logs” and select only the apache access logs.
Benign Log Entries
These are examples of log entries that are safe to ignore:
2019-04-24 18:37:23 Error 220.127.116.11 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 18.104.22.168 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 2019-04-24 18:37:23 Error 22.214.171.124 404 GET /wp-includes/js/tinymce/skins/lightgray/skin.min.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.2 K Apache SSL/TLS access 2019-04-24 18:44:49 Error 126.96.36.199 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 90.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.
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 188.8.131.52 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
Server Log Locations (Shell/Advanced)
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:
Filtering for Dynamic Requests via CLI…
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:
It’s important to understand that:
- Not all requests with query parameters (containing /?) will be dynamic, but we include them here in case at least one of them does.
- 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"