Mass-market hosting sells a pack: a domain, a mailbox, a panel and a ticket queue. The first line checks whether the domain points at the server, whether PHP is on and whether the account hit a limit. For ordinary problems that is enough.

A store outage in campaign hour is a different problem. The database does not answer, the disk is busy, a certificate expired, or another customer backup loads the same server. The ticket still lands in the same queue as a password reset. Meanwhile the cart returns an error, ads keep running and marketplace orders fail.

What you actually buy in the contract

On mass hosting you buy first-response time, not repair time. A stated 99.9 percent monthly availability still allows about 43 minutes of downtime. At a sales peak that is a lost campaign.

A reply in 15 minutes is often automatic. A database restart, moving the account to another server and restoring a copy are rarely in the same sentence of the contract. You also do not have full server access. You cannot restart services, put up your own status page, or often reach the person who can work on the node.

How the queue looks in an outage

The first line sets the priority of a “store is not selling” ticket. If the script says “CPU limit, upgrade the pack”, the case may stop there even when the cause is a sick host disk. The second line works across many servers. Your ticket waits behind someone else’s restore. On Black Friday the queue is shared by every customer of the “store” offer.

The effect is measurable. The cart does not close payment. The gateway times out and duplicates or drops the order. Marketing pays for a click that ends in an error.

What to set before you buy the pack

In the contract, not in the FAQ: how long to restore payment, which channel sits outside the web queue, who may restart the service. Ask about the copy: how often, whether it was tested, whether it sits on the same host.

Before you rely on the vendor, have your own monitoring of the cart, not only the homepage. The alert should go to you. A log that stays with you still shows which layer failed when the host is silent.

If the answer to a store outage is a ticket in a queue, that model often is not enough. Then your own machine, on-call with an agreed scope and one channel: IT administration. Magento and PrestaShop care: ecommerce. Shared account resources: shared hosting.

In short: what matters is the time from “the store is not selling” to a person with rights. The contract and your own cart monitoring, not a support promise on the offer page.