Where to find and how to read PrestaShop logs
PrestaShop records its errors in three different places depending on their nature: its own logs table, a folder of files, and the server's own logs. Knowing which one to check first saves most of the diagnostic time.
The three log sources, in the order to check them
-
The Logs tab in the back office
Accessible from Advanced Parameters > Logs, it lists errors and warnings generated by PrestaShop itself, with a severity level, the time, and often the PHP file involved. This is the first source to check if the back office is still reachable.
-
The var/logs folder
From PrestaShop 1.7.4 onwards, and so on 8 and 9, this folder holds the logs generated by the underlying Symfony framework, split by environment (prod.log, dev.log). On 1.7.0 to 1.7.3, those same logs live in app/logs instead. The folder is only accessible via FTP, SFTP or SSH.
-
The server logs
The hosting panel (cPanel, Plesk, or direct SSH access) gives access to the PHP error logs and the web server logs (Apache or Nginx), which record errors that occur even before PrestaShop starts running.
-
Cross-check the timestamp
The common thread between all three sources is the time of the incident. Pinpointing the exact moment the problem appeared makes it possible to find the same error across several logs and confirm the cause.
-
Enable debug mode as a backup
If no log is precise enough, temporarily enabling _PS_MODE_DEV_ in config/defines.inc.php displays the error live on the page concerned, with the full call stack.
[2026-07-24 09:14:02] request.CRITICAL: Uncaught PHP Exception ... {"exception":"[object] (Error(code: 0): Call to undefined method ..."}What each source reveals, and what it doesn't
The Logs tab in the back office is convenient because it requires no particular technical access, but it only works if PrestaShop manages to start up enough to write to the database. An error occurring very early in the loading process, or a problem connecting to the database itself, will never show up there.
The var/logs folder captures a wider range of errors, including ones that prevent a page from displaying fully, but it's still specific to the application: a server configuration error, insufficient PHP memory, or an invalid .htaccess file will leave no trace there.
The server logs are the last line of defence: they see everything happening at the web server and PHP level, including errors that stop PrestaShop from running at all. That's where to look when neither the back office nor var/logs explains anything.
Common mistakes
- Searching only in the back office when the site is completely offline: in that case, the Logs tab itself is probably unreachable.
- Ignoring the timestamp and reading the first message found, which could be weeks old and unrelated to today's incident.
- Never rotating or clearing the logs: on an older store, these files can reach several gigabytes and become hard to work through.
- Confusing a "warning"-level message with the real cause of a 500 error: only critical or error-level messages deserve priority attention.
Frequently asked questions
I have no FTP access, can I still check the logs?
Do the logs contain my customers' personal data?
How long are the logs kept?
The error message is in English and very technical, is that normal?
Describe your need in one minute
A few targeted questions so I can reply with an estimate rather than another questionnaire.