Monitoring
5xx error spikes during traffic surges: why your store goes down the moment a campaign succeeds
Richard K. · October 30, 2026 · 9 min read
There's a particular kind of bad morning: the email campaign you spent three weeks building finally goes out, the open rate is strong, the click-through is even better, and for about four minutes your store is making real money. Then the orders stop. Not because people lost interest. Because your server started throwing 500 and 503 errors at a meaningful fraction of visitors, and nobody noticed until the support inbox filled up.
This is one of the crueler ironies in ecommerce: your worst outages often happen on your best days. A quiet Tuesday rarely breaks anything. A successful promotion, a viral post, a influencer mention, or a well-timed flash sale can overwhelm infrastructure that handled every normal day just fine. The traffic that should have been your biggest win becomes your most expensive failure.
Why a successful campaign is a stress test you didn't schedule
Marketing and infrastructure rarely talk to each other until something breaks. A campaign manager schedules a send for 9am Tuesday because that's when open rates peak. Nobody tells the person responsible for hosting that 40,000 emails are about to land at once, each one a potential click within the same ten-minute window.
Under normal traffic, your store's database, checkout logic, app integrations, and CDN are all comfortably under capacity. An ecommerce traffic spike compresses a day's worth of visits into minutes. Database connections queue up. Apps that call external APIs for shipping rates, reviews, or recommendations start timing out. Your server, instead of serving a page, returns a 500 Internal Server Error, a 502 Bad Gateway, or a 503 Service Unavailable, depending on where the chain breaks.
The frustrating part is that these errors are often intermittent. One customer loads the page fine. The next, hitting the server a half-second later when a resource pool is exhausted, gets an error page. Refresh, and it might work. This intermittency is exactly what makes the problem so easy to miss from the outside and so damaging on the inside: your conversion rate quietly craters while the site technically 'stays up.'
Why your uptime monitor doesn't catch it
Most store owners have some form of uptime monitoring, even if it's just a free tool pinging the homepage every five minutes. That's useful for catching a fully dead site, but it's the wrong tool for this specific failure mode.
An uptime check is a sample, not a feed. If your homepage returns a clean 200 OK at 2:00:00 and another clean 200 at 2:05:00, the monitor reports perfect uptime, even if 30% of requests between those two checks came back as 5xx errors. A traffic spike that causes intermittent server errors can hide entirely in the gaps between pings.
Uptime checks also usually hit one page, often the homepage, which is frequently cached and lightweight. The pages under the most strain during a sale are checkout, cart, and product pages, where database writes, inventory checks, and third-party app calls all happen. A monitor that only confirms the homepage loads is checking the part of your site least likely to fail and ignoring the part most likely to.
This is the same blind spot that shows up in zero orders in an hour: how to tell a slow day from a broken storefront: the dashboards that look fine and the reality on the ground can diverge sharply, and the only way to close that gap is to watch the signals that actually correlate with revenue, not just the ones that are easy to check.
Where the bottlenecks actually live, by platform
Shopify downtime during a sale is rarely Shopify's core infrastructure failing outright; Shopify's platform is built to absorb large swings in traffic. More often, the failure point is a third-party app, theme logic, or an API call to an external service (loyalty programs, review widgets, personalization engines) that wasn't built for a sudden surge. When that external call hangs, it can hold up the whole page render, and depending on how the app is integrated, that shows up as a timeout or a 5xx error to the visitor.
WooCommerce runs on infrastructure you (or your host) control directly, which means a site crash during a promotion is often a server resource problem: PHP workers maxed out, database connections exhausted, or a hosting plan that was sized for average traffic, not peak traffic. WooCommerce stores are particularly exposed here because the gap between "fine on a normal day" and "falling over during a spike" can be a single undersized hosting tier.
BigCommerce sits somewhere in between, with managed infrastructure similar to Shopify's but its own set of app and API integration points that can become bottlenecks under load. For a fuller rundown of what to watch on that platform specifically, see how to monitor a BigCommerce store: the checks Shopify and WooCommerce guides don't cover.
Across all three platforms, apps are a recurring theme. Each one you've installed adds a call that has to succeed, quickly, under load, or it becomes the thing that fails first. If you've never audited how many of those calls are riding on your critical path, how many apps is too many? The real cost of plugin bloat in your store is a useful starting point.
The outage that costs you the most is the one that happens while you're winning.
What real-time error-rate monitoring actually looks like
The fix isn't to stop running successful campaigns. It's to monitor the thing that actually predicts a problem: the rate of server errors, measured continuously, not sampled every few minutes.
Server error monitoring worth having checks multiple page types, not just the homepage, including product pages, cart, and checkout, since those carry the database and API load that breaks first. It should flag a rising error rate as a trend, not wait for a single failed check, since a jump from 0.1% to 8% of requests returning 5xx errors is meaningful well before it reaches 100%. And it should alert you through a channel you'll actually see quickly (SMS, Slack, phone call) rather than an email that sits unread during the exact hours you're busiest watching the campaign's performance metrics.
This is the gap Cassian™ is built to close. Rather than a single uptime ping, Cassian's continuous monitoring tracks error rates and response health across your store in real time, so a spike in 5xx errors during a traffic surge shows up as an alert within minutes, not as a drop in sales you notice hours later. The Cassian Score™ also rolls this into an overall health view, so a rising error rate registers as a signal worth investigating even before it becomes a full outage.
If you know a surge is coming, whether from a planned sale or a campaign with real reach, testing your limits in advance beats discovering them live. Stress-testing your Shopify theme and apps before Black Friday: a load-testing checklist and traffic spikes of 500 percent in 30 minutes: capacity planning for small stores both walk through how to find and shore up your weak points before the real traffic arrives.
Frequently asked questions
- Why does my store go down only during sales or big marketing pushes?
- A store typically goes down during sales because the sudden concentration of visitors overwhelms a specific bottleneck, such as an app's API calls, database connections, or hosting resources, that handled normal daily traffic without issue. The failure is usually not your core platform crashing outright but one dependency in the request chain timing out under load and returning a 5xx error to a portion of visitors. This is why the problem often appears only during traffic spikes and not on an average Tuesday.
- Can my uptime monitor catch a 5xx error spike during a traffic surge?
- A basic uptime monitor that pings your homepage every few minutes usually cannot catch a brief 5xx error spike, because it only samples the site at fixed intervals and often checks a lightweight, cached page. An error burst affecting checkout or product pages for several minutes can occur entirely between two successful homepage pings, leaving the monitor's uptime record clean while real customers hit error pages. Continuous error-rate monitoring across multiple page types closes this gap.
- What should I do if I see 500 or 503 errors spiking during a promotion?
- If 500 or 503 errors spike during a promotion, first check whether the errors cluster around a specific page type (checkout, cart, product pages) or a specific app integration, since that points directly to the bottleneck. Contact your hosting provider or platform support with the error timestamps and affected URLs, as they can often identify whether the cause is a resource limit, a database lock, or a third-party API timeout. Afterward, consider load testing before the next planned traffic event so the same limit doesn't get hit again.
Turning a good day back into a good day
A campaign that drives real traffic is a sign you're doing something right. The goal isn't to fear that success, it's to make sure your infrastructure can carry it without silently turning customers away at the door. That means watching error rates continuously, not just confirming the homepage loads, and knowing your capacity limits before a big push finds them for you. The stores that handle a surge well aren't the ones with the most expensive hosting; they're the ones who saw the problem in the first few minutes instead of the next morning.