Hosting escalation when the store is not selling
Opselis
L1 reads a script. L2 has access to the node. The ticket waits in the same queue as a password reset. RTO in the contract and your own monitoring, not a support promise on the offer page.
Mass-market hosting sells a pack and a ticket queue. The first line checks whether the domain points at the server, whether PHP is on, whether the account hit a limit. A store outage at peak is a different problem: the database does not answer, the host disk has high await, a neighbour ate I/O, a certificate expired, the mail queue blocked cron. The ticket reaches someone with hypervisor access through that same queue. Meanwhile checkout returns 502, ads keep running, marketplace orders error. The tool on your side is the contract (RTO, channel, a named person) and monitoring that sits with you, not a “support around the clock” line on the offer page.
What escalation is for
Escalation should shorten the time from “the store is not selling” to a person with rights. On mass hosting you buy L1 first-response time, not repair time. A 99.9 percent monthly SLA still allows about 43 minutes of downtime. At peak that is a lost campaign, not an incident within bounds. A reply in 15 minutes is often an autoresponder. A MySQL restart, moving the account to another node and a restore are not in the same sentence of the contract.
You do not have root. You cannot restart php-fpm, fail over, or put up your own status page. The vendor panel may be down with the host. The helpdesk phone does not reach the node administrator.
How the queue works in an outage
The ticket lands in the same bucket as a password reset and a WordPress install request. L1 sets the “store is down” priority. If the script says “CPU limit, upgrade the pack”, the case does not go further, even when the cause is a sick host disk. L2 works across tens of nodes. Your ticket waits behind someone else’s restore. On Black Friday the queue is shared by every customer of the “store” offer.
Communication is email. You often have no vmstat dump, because there is no root. They ask for a Resource Usage chart that will not load. There is no named engineer: each shift change reads the history from zero.
The effect is measurable. The cart does not close payment. The gateway times out and duplicates or drops the order. Marketplace stock drifts from the warehouse. Marketing pays for a click that ends in 502. Escalation time is counted from lost revenue, not from the ticket number.
How to set on-call before you buy the pack
In the contract, not in the FAQ: RTO on checkout (for example 30 minutes to restore payment), a channel outside the web queue, who may restart the service and move the VM. Ask about maintenance: whether you get a window, or a node restart comes with no notice. Ask about the copy: RPO, a restore test, whether the copy sits on the same host.
Before you rely on the vendor: an HTTP probe on the cart, not only the homepage. An alert to you. Cloudflare in front of origin. A log that stays with you. When the host is silent you still know which layer failed.
If the answer to an outage is an L1 ticket, that model does not hold a store. Then a VM with root, on-call with a playbook and one channel: IT administration. Magento and PrestaShop care: ecommerce. Shared account resources: shared hosting.