What happened
The spike. At 11:48 a large design publication featured the store, two days earlier than planned, and readers started arriving. Nobody had changed anything on the site. Orders rose quickly, to about four times the normal rate, and at 12:00 Operanse marked this as unusual activity, not a problem.
The hosting limit. The hosting plan had a fixed CPU allowance and a limited number of PHP workers, and its page cache did not cover carts or checkout. At 12:10 CPU reached 85 %, against about 22 % normally at that hour. By 12:15 it was above 90 %, and placing an order took 6.4 seconds instead of the usual 1.3.
Checkout fails. At 12:20 PHP started running out of memory, and from 12:22 no orders went through at all.
The alert. At 12:30, after CPU had stayed above 90 % for fifteen minutes, Operanse sent a critical alert: CPU at 97 %, memory at 99 %, checkout at 6.4 seconds, no orders since 12:22, and no recorded change to the site.
Recovery. The developer raised the hosting plan’s resource allowance at 12:50, and it took effect at 13:10. CPU and memory returned to normal, orders resumed, and the incident closed at 13:25.
The lunchtime, replayed. The bottom two rows are the server’s CPU and memory, which are monitored on the Insight plan.
The traffic spike that took the host down. A lunchtime four times the usual, with no change behind it, that ran the host to 100 % and stalled checkout. Unusual at 12:00, messaged at 12:30 once CPU had been above 90 % for fifteen minutes, over when the host came back.
- 12:00Orders · Unusual: 12 orders in the last 15 minutes, against about 7 normally · busier than usual, not a fault
- 12:10CPU · Warning: 85 % on a host that sits near 22 % at this hour · added to the daily digest; an alert if it holds 90 % for 15 minutes · Insight
- 12:15Checkout · Unusual: 6.4 s to place an order at the median, usually about 1.3 s · memory at 88 %
- 12:25PHP errors · Warning: 5 fatal errors in 5 minutes, memory exhausted, usually none · added to the daily digest, no alert sent
- 12:30CPU · Critical: CPU at or above 90 % for 15 minutes · alert sent · message sent
The host is saturated: CPU 97 %, memory 99 %, checkout at 6.4 s, and no order has been placed since 12:22. No change is recorded today. - 12:35Orders · Warning: 0 orders in the last 15 minutes, against about 6 normally, after 36 in the half hour before · added to the incident alerted at 12:30
- 13:05Orders · Critical: orders well below normal for 30 minutes · alert sent · message sent
About $980 has not been taken since 12:35, against this store’s usual for the hour. Carried as an estimate on the same incident. - 13:15Host · Back near usual: CPU 35 %, memory 63 %, no fatal error since 13:10
- 13:25Orders · Resolved after 75 minutes: the server and the orders both back to normal
What happened next
The developer read the alert on their phone during a meeting. Because it said no change had been recorded, they could rule out a bad release; because it gave CPU and memory figures, they went straight to the hosting control panel, which confirmed the account had exceeded its resource allowance. The host’s status page was green throughout: the host was fine, but the plan was too small.
At 13:05 a second alert on the same incident estimated $980 in orders not taken since 12:35, compared with a normal lunchtime. The real loss was larger: the extra orders the press feature would have brought in while the store could not take them.
How to prevent it
- Share the marketing and press calendar with whoever manages hosting, and scale the plan up before a launch, after a load test on staging at several times the normal peak.
- Make sure full-page caching covers every page a visitor can reach from a press feature, with cart and checkout excluded as they must be.
- Turn on the host’s own resource alerts and send them to the developer’s phone.
- Monitor server resources alongside orders. Here the CPU alert arrived thirty-five minutes before the orders alert.
Related tools and examples
- Check your WooCommerce system status report: it flags a PHP memory limit or time limit too low for a busy day, before the busy day.
- Check whether your checkout is being cached: the cart and checkout must not be cached, so they are the pages that carry the load in a spike.
- Estimate what the outage cost: use “Orders stopped” and set how busy the hours were above normal. The figure counts orders not taken at your usual rate, so it understates a spike like this one.
How Operanse catches it
Orders are compared with the store’s normal pattern, because an empty quarter hour means something different at lunchtime than at 03:00. Server resources are judged against fixed limits instead: CPU at or above 90 % for fifteen minutes is critical on any store at any hour, so a new store is covered from its first day, before its normal pattern has been learned.
CPU and memory are read from inside WordPress, which works even on managed hosting where you cannot install server software. On Monitor, which does not include server monitoring, the orders alert at 13:05 would have reported the same incident, thirty-five minutes later.
Operanse compares each store’s activity with its own history and groups related anomalies into incidents. Playback, the replay above, is on Monitor and Insight; Insight adds server monitoring and an AI review of the likely cause, with its evidence. How Operanse monitors a WooCommerce store.