Which logs does ISPmanager 6 keep
The panel keeps three groups of logs: web server logs for each site, the panel's own logs, and logs of system services such as mail and databases. Some logs can be viewed right in the interface — the "Domains → site → Logs" section — but for deep diagnostics it is more convenient to look at the files directly through the server console.
If an error appeared right after switching the web server, first check the combo setup — it is described in the article Nginx and Apache together in ISPmanager 6: some 502 and 504 errors are related exactly to proxy settings.
Where site logs live on disk
Each site's logs are stored in a separate user folder, and the path follows a fixed template.
| Log | Path | What to check |
|---|---|---|
| Nginx access log | /var/www/user/data/logs/example.com.access.log | all requests to the site |
| Nginx error log | /var/www/user/data/logs/example.com.error.log | web server errors |
| PHP error log | /var/www/user/data/logs/example.com.php.error.log | PHP errors and warnings |
| Panel log | /usr/local/mgr5/var/ispmgr.log | administrator actions |
Replace example.com and user with the actual domain and user login — the panel creates these files automatically on the first request to the site.
How to read the web server error log
The fastest way to find why a site is failing is to open the last lines of the error log right after reproducing the error:
tail -n 50 /var/www/user/data/logs/example.com.error.log
To watch the log in real time while testing, use a live tail filtered by the 500 response code:
tail -f /var/www/user/data/logs/example.com.access.log | grep ' 500 '
The line with the timestamp, code, and request path usually points right away to which script failed.
Common error codes and what they mean
Web server response codes are the first clue during diagnostics.
- 502 Bad Gateway — Nginx did not get a response from Apache or PHP-FPM, check whether the corresponding process is running.
- 504 Gateway Timeout — the backend did not respond in time, usually because of a slow database query.
- 500 Internal Server Error — an error in the site's code, check php.error.log for details.
- 403 Forbidden — missing file permissions or access denied in the web server config.
Diagnosing PHP and database errors
If a site shows a blank white screen with no error text, PHP error output is disabled in production — that is correct from a security standpoint, but inconvenient for debugging. Temporarily enable error output in a test environment through the site's PHP settings, not in the server's shared php.ini.
Database connection errors usually mean the MySQL service is stopped or the connection limit is exhausted. You can check the service status and the last lines of its own log like this:
systemctl status mysql
tail -n 30 /var/log/mysql/error.log
Diagnostics at the panel level
If the problem is not with the site but with ISPmanager 6 itself — for example, the interface does not open or an operation hangs — first check the panel daemon's log and process status:
systemctl status ihttpd
tail -n 100 /usr/local/mgr5/var/ispmgr.log
Repeated errors in this log after a panel update are a reason to check the guide updating ISPmanager 6: order and rollback and verify the panel did not get stuck on an intermediate version.
A diagnostic checklist from simple to complex
Work through the problem step by step instead of trying to cover everything at once.
- Check the error code in the browser and the site's access log — this narrows the search area.
- Open the web server error log and php.error.log for the same moment in time.
- Check the status of dependent services: PHP-FPM, MySQL, Apache in a combo setup.
- If the error only reproduces in the panel, check ispmgr.log and the ihttpd status.
This order saves time: in nine cases out of ten, the cause is visible already at the first or second step.