500 or 522 Error in PrestaShop: what data should be prepared for diagnosis?

Write down the exact address, the time with time zone, and the action after which the error appeared. These three pieces of information make it possible to look for the same event in the logs. The 500 or 522 number alone does not yet indicate which module needs to be changed.

This guide helps you prepare a report for diagnosis. It does not describe the repair of a specific store or present example causes as an established outcome.

What should you write down during a failure?

1. Address and action: e.g. opening a product, saving a setting in the panel, or moving from the cart to delivery. Do not include tokens from the panel address in a public report.
2. Time: date, time, and zone, e.g. 2026-09-26 14:32 Europe/Warsaw. If the problem returns, write down two or three specific occurrences.
3. Response: HTTP code, visible message, and request identifier, if the error page provides it. Supplement the screenshot with the message text.
4. Scope: one address or the entire store, front office or panel, logged-in user or guest, one network or also another one.
5. Last change: update, module installation, import, hosting setting change. Provide the date; the sequence of events alone does not prove the cause.

Error 500 and error 522 require different starting points

Description of 522 and recommendations for the connection to the origin server: Cloudflare documentation. General meaning of status 500: HTTP Semantics, RFC 9110.

How to prepare a simple reproduction attempt?

Example demonstration report: “At 14:32 I open the product page as a guest. The document has status 500. The homepage works in the same browser. At 14:35 the same product works from another network.” Such a note does not diagnose the cause, but it points to specific requests for comparison.

With each repetition, change one condition and write down the result. If you clear the cache, change PHP, and disable several modules at the same time, it will be difficult to determine which change affected the store’s behavior.

Which logs should be provided to the person diagnosing the issue?

Ask for a check of a short time range around the event: the application log, PHP errors, and the web server log, and in the case of an intermediate layer, also its events. Where logs are stored depends on the store version and hosting configuration. Instead of assuming a path, provide the administrator with the exact time, address, and request method, if you know it.

Log excerpts may contain email addresses, session identifiers, and order data. Share the necessary excerpt through an agreed channel and remove secrets. A full HAR file may also contain such information; do not publish it as a regular attachment on a forum.

How to compare layers without changing the protection of the entire store?

A comparison of responses through the CDN and directly from the server should be prepared by an administrator familiar with the domain, TLS, and origin access configuration. A difference between the responses is a clue for further testing, not automatic proof that the WAF or PrestaShop is at fault.

Use debug mode on a working copy or with controlled access. Globally disabling protection or showing detailed exceptions to all visitors is not necessary to prepare a useful report.

Ready-made report template to download

Download the failure description form — TXT. Fill in the fields, and mark missing information as “not checked”. The form does not require passwords or API keys.

What should be checked after the fix?

Repeat the recorded steps under the same conditions, check the result of the action and the new entries in the logs. In the case of an intermittent problem, one successful page load confirms only that one attempt. Agree with the contractor on the observation period, the scope of tests, and the signal for reporting again.

If the problem appeared during a version change, also use the PrestaShop update preparation checklist. A separate guide explains the role of HTTP security headers.