How to avoid a 500 error visible to your customers

What 500 and 503 errors really mean

A 500 error indicates a server-side problem while processing the page: often an unhandled exception, an incompatible module or a missing dependency. The page does not display at all.

A 503 error signals that the service is temporarily unavailable: overloaded server, maintenance mode badly lifted, or saturated resource. The customer concludes the store is "down".

In both cases, the commercial impact is immediate: a visitor landing on an error page leaves the store, often without returning. These errors must therefore be treated as critical incidents.

The common causes of errors after publishing

The most common cause is a module or plugin incompatible with the version in place: a removed function, an absent dependency, and the page throws a 500 as soon as it is called.

The cache also plays a role: a cache not rebuilt after an update can serve inconsistent files and trigger errors. On Magento, an incomplete compilation has the same effect.

Finally, 503 errors often arise during publishing itself: maintenance mode left active, or an unanticipated load spike at the moment traffic returns to the store.

The method: test the key pages before publishing

Before publishing, run the critical pages on a preview: home, product page, cart, checkout flow and back office. Check that each returns a 200 code, not an error.

Check first the modules touched by the change, as they cause most 500 errors. Rebuild the cache and, on Magento, verify the compilation before testing.

DriftOps automates this check: it spots 500 or 503 errors on the preview and blocks publishing as long as the status is not healthy. Production only receives a verified version.

Discovery in production vs detection in preview

Without a prior check, the 500 error is discovered in production, reported by a customer or by a traffic drop. The fix is then made in an emergency, under pressure.

With detection in preview, the error is caught before going live, on a copy. You fix calmly, revalidate, then publish a version you know responds correctly.

Use case: a module calling a removed function

A PrestaShop module is updated, but it calls a function removed in the core version in place. On the preview, the product page returns a 500 error.

Because the check happens before publishing, the live store stays open while the team fixes the module's compatibility on the copy.

Once the product page is back to a 200 code and the path verified, the change is published without any customer ever seeing a broken page.

Anti-500/503 checklist before publishing

Check these points before every go-live.

• Home, product page, cart and checkout return a 200 code.
• Back office accessible without error.
• Touched modules tested and compatible with the version in place.
• Cache rebuilt (and compilation verified on Magento).
• Maintenance mode properly lifted after publishing.
• Load anticipated to avoid a 503 when traffic returns.
• Rollback ready if an error appears anyway.

Measuring the prevention of server errors

Watch the 500 and 503 error rate on critical pages after each release. The goal is to keep it at zero on the customer side.

Also count the errors caught in preview: each one is a broken page your visitors never saw.

Conclusion: a server error is seen before customers

500 and 503 errors are among the most damaging for a store, because they cut the purchase path dead. They are also among the most avoidable.

By testing the key pages and HTTP codes on a preview, and keeping a rollback ready, you avoid a public and costly outage. DriftOps protects this validation moment.