For a typical store monitoring 10 to 20 vendors, the realistic answer is somewhere between zero and four alerts a month, and most months land at the low end. Across all 84 services StatusBird checks, August 2026 produced 16 major or critical incidents touching 9 services, and March 2026 produced just 2 incidents across 2 services.
That is the number people actually want before they turn on monitoring. The fear is not missing an outage, it is getting buzzed at 2am every other night until you mute the whole thing. The data says that does not happen, as long as you monitor the services you depend on rather than everything available.
What do six months of outage data say about alert volume?
Here is the monthly count of major and critical incidents across all 84 monitored services, from the StatusBird outage index.
| Month | Major/critical incidents | Combined downtime | Services affected | Most affected |
|---|---|---|---|---|
| August 2026 | 16 | 40.4 hours | 9 | Plaid |
| July 2026 | 14 | 22.1 hours | 8 | Shippo |
| June 2026 | 8 | 37.0 hours | 8 | Squarespace |
| May 2026 | 4 | 21.9 hours | 4 | Square |
| April 2026 | 20 | 122.1 hours | 11 | AfterShip |
| March 2026 | 2 | 8.3 hours | 2 | Authorize.net |
Two things stand out. First, the total across six months is 64 incidents, which averages to roughly 11 per month spread over all 84 services. Second, incidents cluster: in every month above, fewer than a quarter of monitored services had any major or critical incident at all. April 2026 was the worst month with 11 services affected, and even then 73 of the 84 services had a clean month.
So the per-service math is favourable. In August, 16 incidents across 84 services works out to fewer than one incident for every five services monitored. If your stack is 15 services, the statistically expected alert count for a month like August is about three, and in a quiet month like March it rounds to zero.
Which services generate the most alerts?
Alert volume is not evenly distributed, so the specific vendors in your stack matter far more than the number of vendors. Over the 90 days ending September 13, 2026, these services accounted for the bulk of incident activity:
- Shippo: 9 major or critical incidents, 1,332 minutes of downtime, average incident 148 minutes, last incident August 13, 2026.
- Plaid: 4 incidents, 1,548 minutes of downtime, average incident 387 minutes, last incident August 3, 2026.
- ActiveCampaign: 3 incidents, 202 minutes of downtime, last incident August 5, 2026.
- Cloudflare, Deliverr, Shopify, Vercel and Zapier: 2 incidents each.
- ShipStation, Recharge, Affirm, Sezzle, Vertex and ShipMonk: 1 incident each.
Those figures come from StatusBird's independent monitoring at 2-minute intervals over the 90 days ending September 13, 2026. Everything else on the list, including Stripe, PayPal, Klaviyo and UPS, recorded zero major or critical incidents in the window. Adding those to your watchlist costs you nothing in alert volume over a quarter like this one.
A worked example: a typical Shopify stack in August 2026
Say you monitor Shopify, Stripe, PayPal, Klaviyo, Attentive, ShipStation, Shippo, Gorgias, Recharge, Google Ads, Meta Ads and Cloudflare. In August 2026 you would have received alerts for three of those twelve: Shopify on August 27, Shippo on August 13, and Cloudflare on August 12. Three incidents in 31 days. The other nine services stayed quiet all month.
Does one outage mean one alert?
No, and this is where people underestimate volume. A single incident usually produces at least two messages: one when the check starts failing, one when it recovers. If you have routed the same service to both SMS and Slack, that is four notifications for one outage. Multiply by the number of people on the alert list and the perceived noise grows fast even though the underlying incident count has not changed.
Long incidents also feel like more alerts than they are. Plaid's average incident length over the 90 days was 387 minutes. That is one alert and one recovery notice, but it sits in your channel for more than six hours, which reads as an ongoing problem rather than a single event.
How do I keep alerts useful instead of noisy?
Route by revenue impact, not by convenience. Concretely:
- SMS only for checkout-path services. Your storefront, your e-commerce platform, and your payment processor. On the August example stack, that is Shopify and Stripe, which would have produced one SMS in the whole month.
- Slack, Teams or Discord for everything operational. Shipping, fulfillment, subscriptions, helpdesk, tax. A ShipStation or Shippo outage needs a response within the hour, not within two minutes. Send those to a dedicated channel such as #vendor-status rather than your main ops channel.
- Email for marketing, analytics and ads. A Google Analytics or Pinterest Ads incident is something to know about when you next sit down, not something to interrupt a call for.
- One recipient per tier at first. Add teammates after a month of real data. Four people on SMS for twelve services is the fastest way to train everyone to ignore alerts.
- Prune services you do not actually depend on. If you left Plaid enabled but no app in your stack uses it, you inherited four incidents and 1,548 minutes of downtime notifications for nothing.
What about false alarms?
Check interval and confirmation logic matter more than the alert channel here. A monitor that checks every five minutes and fires on a single failed response will alert you on transient blips; a monitor that confirms across consecutive 2-minute checks will not. StatusBird checks each service every 2 minutes and applies confirmation before opening an incident, which is why the counts above are lower than raw failed-request totals would suggest. The methodology page spells out how incidents are opened, classified as major or critical, and closed.
It is worth noting the gap between a vendor's own status page and observed behaviour. Vendor pages are updated by humans after triage, so the same incident can appear in your alerts before it appears on the vendor's page. That is not a duplicate alert, it is the same event arriving from two sources at different speeds. Checking the live Shopify status page or Shippo status page during an alert tells you whether the vendor has acknowledged it yet.
The short version
Monitor 10 to 20 services and you should expect a handful of alerts in a busy month and none in a quiet one. Six months of index data ranged from 2 incidents in March 2026 to 20 in April 2026 across all 84 services. Configure SMS narrowly, put the rest in a chat channel, and the volume stays low enough that you will still read the messages six months from now.
If you want alerts for the specific vendors your store depends on, with channel routing per service, you can set that up in a StatusBird account at statusbird.io/register.