PrestaShop Logs — Where They Are & How to Read Them [2026]

PrestaShop logs are the first place a good specialist looks at for any failure — 80% of problems leave a trace there with the exact error message. In PrestaShop the logs are in the var/logs/ directory, complemented by PHP and server logs. Below: where exactly the logs are in PrestaShop 1.6, 1.7, 8 and 9, how to read them and how to find the cause of a failure in them. Diagnostics with a report by a specialist: 500–1,500 PLN net.

Key takeaway: PrestaShop logs live in three places: 1) var/logs/ in the store directory (daily files: dev.log, prod.log in 1.7+/8/9; log/ in 1.6), 2) PHP hosting logs (error_log, php_errorlog), 3) server logs nginx/apache (error.log, access.log). Look for entries from the last few minutes: PHP Fatal error, Allowed memory size, SQLSTATE, Connection refused. One error a minute before the failure is usually the culprit. Read logs from the bottom — the newest entries are at the end.

Where the logs are in PrestaShop — version by version

You can access the files via FTP/SFTP, SSH or the file manager in the hosting panel. If the var/logs/ directory is empty, logging may be disabled or permissions prevent PHP from writing — that is a separate problem to fix.

PHP and server logs

PrestaShop does not log everything — PHP-level server errors (memory exhaustion, parse errors) end up in the PHP logs

• error_log — in the store directory or the hosting account's root directory,
• php_errorlog — typical for shared hosting (cPanel/DirectAdmin),
• nginx/apache logs — error.log (server errors) and access.log (all requests, useful for attack analysis).

When PrestaShop shows a white screen with no entry in var/logs/, look for the cause in the PHP logs. Without file access, ask hosting support for the latest error entries — they provide them as standard.

How to read logs — a practical workshop

A log entry has a fixed structure: time, level, channel, message. Examples from real failures

[2026-10-20 14:12:03] prod.CRITICAL: Fatal error: Allowed memory size of 268435456 bytes exhausted in /modules/heavymodule/heavymodule.php on line 412

• What it tells you: on 20 October at 14:12 the heavymodule module exhausted 256M of memory. First step: raise memory_limit and check whether the module leaks memory.

[2026-10-20 14:12:03] prod.ERROR: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'shop.ps_temp_table' doesn't exist

A table is missing — a module is looking for a table that does not exist (failed update?

manual database cleanup?). Check whether the module has a complete set of tables.

[2026-10-20 14:12:03] prod.ERROR: Connection refused: SMTP connect failed

The store cannot connect to the SMTP server — wrong port, password or a hosting block. Procedure: PrestaShop emails not sending.

How to filter large logs

A production log can have tens of thousands of lines. Instead of reading everything

• - via SSH: tail -n 200 var/logs/prod.log — the last 200 lines,

• - filter errors: grep -E "CRITICAL|ERROR" var/logs/prod.log | tail -50,

• - search by failure time: grep "14:1" var/logs/prod.log,

• - in PHP logs: grep "Fatal error" error_log | tail -20.

• The rule: look for entries from the minute the problem appeared. One entry just before the failure is usually the culprit.

Logs and debug mode

Logs and debug mode complement each other

• logs always work, including in production — they show history and context,
• debug mode (_PS_MODE_DEV_) shows the full message on screen and enables detailed dev.log logging.

For complex failures the standard procedure is: production logs → store copy with debug enabled → reproduce the error on the copy → read dev.log with the full stack trace. Debug instructions: PrestaShop debug mode.

Access logs — attack diagnostics

The server's access.log is a goldmine of information about attacks

• series of POST requests to admin/, xmlrpc.php, .env files — scanners and brute-force attempts,
• requests to non-existent files (404 codes) from a single IP — reconnaissance,
• unusual User-Agent strings and requests from suspicious geolocations,
• traffic spikes on a single URL — scraping or a DDoS attack.

If you see a compromise (redirects, foreign scripts), the access logs will let you identify the entry point — procedure: PrestaShop store after a hack.

Log rotation and retention

Logs fill up the disk, and their absence makes diagnosing future failures harder

• enable rotation (PrestaShop 1.7+/8/9 does it automatically for var/logs/),
• set server log retention to 30–90 days,
• on an incident, secure a copy of the logs before rotation — it is evidence,
• do not delete logs "to clean up" — that is like throwing away a flight recorder.

Tip: Before reporting a failure to a specialist, collect: the last 50 lines of prod.log, the last 20 Fatal error entries from the PHP logs and the exact failure time. That halves the diagnosis time.

Frequently asked questions

Where are the error logs in PrestaShop?

In the var/logs/ directory (PrestaShop 1.7/8/9) or log/ (1.6). They are complemented by PHP logs (error_log) and server logs (nginx/apache). If var/logs/ is empty, check the PHP logs — the lowest-level errors end up there.

The PrestaShop log is empty but the store is down — what now?

A white screen with no entry in the PrestaShop logs means a PHP/server-level error. Check the hosting error_log and the nginx/apache logs. A common cause: the PHP memory limit or a .htaccess error. Procedure: PrestaShop white screen.

How do I find the cause of a failure in a large log?

Look for entries from the minute before the failure: tail -n 200 var/logs/prod.log and grep -E "CRITICAL|ERROR". The last error before the failure moment is usually the culprit. The exact failure time reported by a customer also helps.

Can I read logs without SSH access?

Yes — you can download the log files via FTP/SFTP or the file manager in the hosting panel. Hosting PHP logs are also often visible in the panel (a "Logs" / "Errors" section). If you have no access, ask support for the latest error entries.

Sources and tools

• PrestaShop DevDocs — logs and debug
• PHP — error handling and logging
• nginx — logs
• OWASP — monitoring and logging

👉 Logs full of errors and the store is down? Send the latest entries and a problem description — contact form or kontakt@informatix.com.pl. See also PrestaShop technical help.

📖 See also: PrestaShop debug mode, 500 error and PrestaShop help.