A PrestaShop shop can fail even when nobody changed the code the day before. No visible update, no new module installed, and yet the site becomes unreachable, payments break or transactional emails stop sending.

The useful approach is therefore not only to repair afterwards. You should distinguish what takes the whole store offline, what breaks a critical function, and what remains silent until the first customer is blocked.

In this article you’ll find a simple checklist, dated 16 September 2026, to know what to monitor automatically and what to check monthly to anticipate a PrestaShop outage before it becomes visible to your customers.

A PrestaShop shop can fail without a visible update

Many resources focus mainly on post-failure fixes: 500 error, white screen, broken module. That’s useful once the site is down. In daily operations, the right reflex is to classify incidents by severity level so you monitor the right points at the right time.

You’ll save time if you separate three scenarios: total outage, a critical function broken, and a silent failure. The priority checks are not the same for each.

What takes the whole site offline

Here the symptom is clear: the shop doesn’t respond, the front won’t load, the back office is inaccessible or a server error is shown. This type of incident can come from the host, a full disk, an expired domain or a technical change applied outside your radar.

If you’re already in this situation, you can compare symptoms with the most common causes of a PrestaShop site outage. The important point here is simple: a total outage is not always linked to a recent deployment.

What breaks only a key function

In this second case, the shop still seems online. Product pages display, the homepage responds, but an essential function no longer works: cart, checkout, payment, customer login or back-office access.

This scenario is deceptive because the problem can persist while the site still responds. You see traffic, but orders are not processed correctly.

What remains invisible until the first customer is blocked

The third scenario is the most misleading. The site stays visible, yet transactional emails no longer send, some resources fail to load over HTTPS, or an external dependency used by a module stops responding.

On an HTTPS-served page, browsers block blocking mixed content. After an SSL renewal or an unfinished domain change, some scripts or styles still called over HTTP can therefore break a function without taking the whole site down.

Silent expirations to prioritise

Forgotten deadlines cause avoidable outages. They often occur outside maintenance windows, at moments when nobody expects an incident.

Your goal is not to memorise these dates, but to take them out of a human head and put them into a documented routine.

Public SSL certificate and origin certificate

An expired public SSL certificate remains a classic. Let’s Encrypt reminds that its certificates are valid for 90 days and that the model relies on automated renewal, not manual: certificate lifetimes for Let’s Encrypt. If automation fails and nobody checks the expiry date, the shop can be blocked overnight.

Often forgotten: if you use a CDN or a proxy, the certificate visible to visitors is not always the only one to monitor. The origin certificate can also expire silently. A common mistake is to check only the padlock in the browser. Avoid that: also check the certificate used between the proxy and the server.

Domain name and renewal

An expired domain name does not necessarily cut the site in the same way across registrars. ICANN indicates that a grace period may exist, but its visible effect can vary. The correct approach is therefore to treat the domain expiry as a firm date, not as a safety margin.

Check monthly: the expiry date, renewal mode, payment method and the person actually responsible for the registrar account. A classic case: a domain still tied to a former agency, an ex-employee or an email address that is poorly monitored.

Module licences and external dependencies

An expired module licence does not always take the whole shop down. However it can block a critical function, an API access or prevent a required update. This is typically the kind of incident that leaves the front available while a business brick becomes unusable.

The good practice is to keep a simple inventory: module name, business role, licence expiry, any external dependency, owner and a test to run after renewal. Without this inventory you often discover the problem on the day payment, carrier or sync fails to respond.

Host-side changes that can break the shop overnight

Hosting is not just scenery. It’s a source of outages in its own right. A shop stable for months can fall out of balance after a PHP version change, insufficient memory or a saturated disk.

On this point, preventive checks are better than an incident ticket after the outage.

PHP version and memory: the duo to monitor closely

A PHP change applied by the host can break a shop without any modification on your side. For PrestaShop 9, the official documentation recommends PHP 8.5 and a minimum memory_limit of 512M: PrestaShop 9 system requirements. It also reminds you to test theme, modules and customisations before going to production.

As of 16 September 2026, PHP notes that a branch receives 2 years of active support then 2 years of security fixes. On that date, PHP 8.2 is no longer actively supported and its security end-of-life is set to 31 December 2026: supported PHP versions. That does not mean you should change blindly. It means a PHP decision must be dated, tested and documented.

A common mistake: letting the host change PHP and then checking only if the homepage still loads. Avoid that: also test the back office, cart, checkout and transactional emails. If you’re preparing an upgrade, you can also reread what to check before a PrestaShop version upgrade.

Full disk, inode exhaustion and a database that won’t write

When the disk is full, symptoms can be abrupt: writes to the database fail, the back office becomes unstable, orders no longer save correctly. cPanel, for example, documents the MySQL error “Got error 28 from storage engine” as a symptom of a full disk: MySQL error 28 related to storage.

This problem often stays quiet until the critical threshold. The shop seems normal, then a write task fails and several symptoms appear at once. The useful check therefore covers not only total disk space but its trend, logs, backups, cache files and inodes if your host limits them.

If the outage is already visible on the server side, a useful first step is to run a PrestaShop 500 error diagnostic to distinguish an application issue from an infrastructure issue.

Why the site can stay online while orders are already being lost

An accessible shop is not necessarily an operational shop. The cost appears when an order isn’t confirmed, a password can’t be reset or a payment fails silently without immediate alert.

These partial outages often last longer precisely because no page seems completely down.

Email quota, queues and broken deliverability

Reaching an email quota does not necessarily take the site offline. However it can block the sending of order emails, account creation messages or password resets. That’s an important difference: the customer thinks they ordered, but receives nothing.

Points to monitor are simple: sending volume, deferred messages, failures, full mailboxes, mail storage quotas and inode saturation on the mail side. A classic mistake is to check only that the SMTP server responds. Avoid that: also verify that messages actually leave, within what delays, and whether bounces or queues are accumulating.

Checkout, payment and blocked scripts without a total outage

After a poorly finalised SSL renewal, a domain change or a resource still called over HTTP, some parts of the checkout can stop working while the shop stays visible. The browser then blocks blocking mixed content.

The typical symptom is a partially loading funnel, a step that loops, an inactive payment button or a third‑party script that no longer initialises. If you notice this type of partial failure, a useful first step is to request a pre-audit for a failing PrestaShop payment to quickly isolate the failing component.

The minimal monitoring to set up to be alerted before your customers

Effective monitoring is not limited to a ping on the homepage. A shop can respond with HTTP 200 while the cart is broken, payments error out or emails stop sending. The right approach combines automated alerts and a documented monthly check.

As of 16 September 2026, this framework can remain simple: a few well-followed checks are better than an overly broad setup that is never maintained.

Automated alerts to configure

First level: availability. You must be alerted if the homepage stops responding or its behaviour changes abnormally.

Second level: expiries. Schedule reminders for the SSL certificate, the domain name and licences for critical modules.

Third level: business functions. Provide at least a regular check of the back office, cart, payment and one transactional email send. This level catches silent failures before your customers do.

Monthly checks to document

Once a month, always run the same checklist:

The decisive point is to assign an owner to each check. A checklist without an owner is often forgotten. If you prefer to delegate this monitoring, monthly maintenance for a PrestaShop shop creates a routine that’s followed over time.

Put an anti-outage checklist in place this week

You don’t need to rebuild everything to reduce risk. The main thing is to take critical points out of improvisation. Start by listing expiries, business tests and responsible people. Then adjust tooling.

The 30-minute checklist to start from a clean base

  1. List your expiries: SSL, domain, licences for critical modules.
  2. Note the active PHP version and the actual hosting environment used.
  3. Check available disk space and saturation signals.
  4. Verify email quotas and the state of transactional sends.
  5. Test a short journey: homepage, product page, add to cart, checkout, email.
  6. Identify who receives alerts and who intervenes first.

This base already helps structure the most useful checks for the silent causes described above. The common mistake is to perform these checks only once. The right rhythm is monthly, with a written dated record.

When to move from in-house checks to external support

If you depend on several providers — a host, a CDN and third-party modules — coordination quickly becomes the weak point. Once nobody is clearly responsible for monitoring, it’s safer to formalise recurring or scoped one-off support.

If you keep control in-house, use this checklist as the basic procedure before opening a ticket. If monitoring has no clear owner, occasional or monthly PrestaShop support can frame both monitoring and intervention. At KLN-WEB I also intervene directly for merchants and white-label for agencies, with a free diagnosis and a reply within 24 hours.

Frequently asked questions

Why can a PrestaShop shop fail with no apparent updates?

Because an outage does not always come from deployed code. A shop can fail due to an expired SSL, an unrenewed domain, a PHP change applied by the host, a full disk or an expired module licence. In many cases nobody touched the site the day before, but operations drifted to a breaking point.

How can I know in advance if the SSL certificate or domain will expire?

The most reliable approach is to combine an automated reminder with a documented monthly check. Verify the public certificate expiry and, if you use a proxy or CDN, also check the origin certificate. For the domain, never assume a grace period will save you: record the expiry, renewal mode and the person responsible for the registrar account.

Can a PHP version change by the host break PrestaShop overnight?

Yes. A PHP change on the host can push your shop outside its compatibility range or reveal insufficient memory. The risk increases if theme, modules or customisations were not tested on that version. Monitor the active PHP version, date and document any technical decision and test front, back office and checkout after changes.

Which quotas should I watch to avoid a silent outage: disk, inode, emails, database?

First monitor available disk space, because a full disk can prevent database writes and cause abrupt symptoms. Also check inodes if your host limits them, plus email quotas and queues. For the database, the useful check is not only its size but its ability to continue writing without errors at order time.

Why does the site stay accessible while order or password emails don’t send?

Because page delivery and transactional email sending rely on different components. A shop can continue to serve pages while an email quota is reached, a queue grows or a mailbox is full. It’s a classic silent failure: the customer sees the site, but part of the post-order journey already fails.

What minimal monitoring should I set up to be alerted before customers?

Set up three levels. First, an availability alert if the site stops responding. Second, expiry reminders for SSL, domain and critical licences. Third, a regular business check of back office, cart, payment and one transactional email. A simple homepage ping is not enough, because a shop can respond while losing orders.