Wake up for four things: your own storefront, your checkout, the payment processor that actually charges cards, and the platform your store runs on. Everything else, including shipping label APIs, tax engines, review apps, helpdesks, ad platforms and email tools, can wait for a morning digest, because there is almost nothing you can usefully do about them at 3 a.m.
The reason people turn off outage alerts entirely is that they got woken for a Zapier hiccup they could not fix and then missed the checkout failure two weeks later. The fix is not fewer alerts. It is two tiers with two different delivery channels.
What makes an outage worth waking up for?
Apply one test to each service on your stack: if this goes down at 3 a.m., is there an action I can take in under 15 minutes from my phone that saves revenue? If the answer is no, it belongs in the morning tier.
Actions that pass the test:
- Switching your active payment gateway in Shopify admin under Settings, Payments, so cards route through a backup processor.
- Turning off a broken third-party checkout or upsell app that is blocking the buy button.
- Pausing ad campaigns that are spending into a dead storefront.
- Putting a one-line banner on your theme and switching your helpdesk autoresponder to explain the problem.
Actions that fail the test: waiting for a shipping label API to come back, refreshing an analytics dashboard, or watching a review widget fail to load. Labels printed at 8 a.m. instead of 3 a.m. cost you nothing. That distinction is your whole alerting policy.
How often would a night alert actually fire?
Less often than most owners fear for the wake tier, and more often than they expect for the morning tier. Over the 90 days ending September 20, 2026, Shopify recorded 99.9% uptime with 2 major or critical incidents totalling 124 minutes, averaging 62 minutes each, with the most recent on August 27, 2026. BigCommerce recorded 99.86% uptime with 2 incidents totalling 180 minutes, averaging 90 minutes, most recently on September 16, 2026. These figures come from StatusBird's independent 2-minute monitoring over the 90 days ending September 20, 2026.
Compare that with the morning tier. Shippo logged 10 major or critical incidents in the same window, 1,344 minutes of downtime, 98.96% uptime and a grade of C, with the most recent incident on September 17, 2026. Plaid logged 4 incidents but 1,548 minutes of downtime, averaging 387 minutes each, at 98.8% uptime. A store that alerted on every service equally would have been pinged repeatedly by shipping and banking infrastructure while the platform itself was quiet.
You can see the current state of either service at the Shippo status page and its full history at Plaid's reliability page.
Which services go in each tier?
| Tier | Services | Channel | Hours |
|---|---|---|---|
| Wake me | Your storefront URL, your platform (Shopify, BigCommerce, WooCommerce, Magento, Squarespace, Wix), your live payment processor (Stripe, PayPal, Square, Adyen, Braintree, Authorize.net), and any CDN or host your theme loads from (Cloudflare, AWS, Vercel) | SMS, plus a call-through if your phone is on Do Not Disturb | 24/7 |
| Morning | Shipping and labels (ShipStation, Shippo, EasyPost, AfterShip), fulfillment (ShipBob, ShipHero, ShipMonk, Printful, Deliverr), tax (Avalara, TaxJar, Vertex), subscriptions (Recharge, Chargebee, Recurly), marketing (Klaviyo, Attentive, Mailchimp, Omnisend, Postscript, SendGrid), helpdesk (Gorgias, Zendesk, Freshdesk, Tidio), reviews, loyalty, analytics, automation and ad platforms | Slack, Teams or Discord channel plus email | Delivered whenever, read in the morning |
Two edge cases deserve thought. Buy now, pay later providers sit on the boundary: if Klarna, Affirm, Afterpay or Sezzle is a meaningful share of your checkout mix, treat it like a processor. Affirm logged 1 incident of 22 minutes in the 90-day window and Sezzle logged 1 incident of 62 minutes, so the wake-tier load from BNPL is small. Second, subscription billing platforms often run charge batches overnight. Recharge recorded 1 incident of 46 minutes in the window. A failed batch is recoverable in daylight, so keep it in the morning tier and reconcile rather than firefight.
Does a night alert help if the outage lasts longer than you sleep?
Often yes, and this is the argument people miss. Plaid's average incident length over the window was 387 minutes. An incident that starts at 11 p.m. with that profile is still running at breakfast. Knowing it started overnight tells you the failed bank link attempts in your logs are not a code change you shipped, and it gives your support inbox a prewritten explanation before the first ticket arrives.
The counterpart is short incidents. Squarespace averaged 10 minutes per incident across 2 incidents in the window. By the time a night alert reaches you, stirs you awake and you open a laptop, a 10-minute outage is over. This is why the wake tier needs the recovery notification enabled too: the second message telling you it is back is what lets you put the phone down.
How do you set quiet hours without missing the real thing?
- Split the channel, not the list. Send wake-tier services to SMS and morning-tier services to a Slack, Teams or Discord channel. Then mute the chat channel overnight at the app level. You do not need to disable any monitoring.
- Add the SMS sender to your phone's exceptions. On iOS, add the number to a contact and allow it under Focus, People. On Android, mark the contact as a starred contact and allow starred contacts to break through Do Not Disturb. Without this step, the wake tier silently becomes the morning tier.
- Require confirmation before the alert fires. A single failed check can be a routing blip. Monitoring on a 2-minute interval with a confirmation check means the alert reflects a sustained failure, not one unlucky request. StatusBird's approach is described on the methodology page.
- Write the 3 a.m. runbook now. Two lines per wake-tier service: the setting to change and where it lives. Half-asleep you will not improvise a gateway switch.
- Review monthly. If a service in your morning tier caused real revenue loss overnight, promote it. If a wake-tier service woke you three times with nothing actionable, demote it or narrow what you monitor on it.
What if you are a solo operator with no one to hand off to?
Then the honest answer is that your wake tier should be shorter, not longer. Keep it to the storefront, the platform and the processor, and accept that everything else is a morning problem. If you work with an agency or have a developer on retainer, the cleaner arrangement is a shared chat channel that receives both tiers, with SMS on the wake tier going to whoever is actually able to log in and change a setting that night. Volume across the whole stack is not trivial: the outage index recorded 16 major or critical incidents across 9 services in August 2026, totalling 40.4 hours, and 20 incidents across 11 services in April 2026, totalling 122.1 hours. Routing all of that to one phone is how people end up ignoring alerts.
One last thing worth checking: whether your alerts depend on the same infrastructure your store does. If your only notification path is an email that routes through the provider currently having the outage, you will find out from a customer instead. Keep at least two independent channels on the wake tier.
If you want this split without building it yourself, StatusBird monitors around 84 e-commerce services plus your own storefront every 2 minutes and sends alerts by SMS, email, Slack, Teams and Discord, so you can point the wake tier at one channel and everything else at another. You can set it up at statusbird.io/register.