Six of the 84 services StatusBird monitors recorded their most recent major or critical incident inside the last 30 days: Shippo, Cloudflare, Squarespace, Deliverr, Shopify and Zapier. Not one of them is a payment processor, an email or SMS platform, an ad network or a marketplace, which means a store watching only Stripe and Klaviyo would have seen a perfectly quiet month while its shipping and automation layers broke.
The figures below come from StatusBird's independent 2-minute monitoring over the 90 days ending September 11, 2026. One caveat before the numbers: the per-service incident counts and downtime totals are 90-day totals, not 30-day totals. What the recent window tells us is which services broke most recently, and the 90-day and monthly index data tells us how much that breakage actually cost in minutes.
Which services had incidents in the last 30 days?
| Service | Category | Most recent incident | Incidents (90d) | Downtime (90d) | Avg incident | Uptime (90d) |
|---|---|---|---|---|---|---|
| Shippo | Shipping | Aug 13, 2026 | 9 | 1,332 min | 148 min | 98.97% |
| Cloudflare | Infrastructure | Aug 12, 2026 | 2 | 142 min | 71 min | 99.89% |
| Squarespace | E-commerce | Aug 12, 2026 | 2 | 20 min | 10 min | 99.98% |
| Deliverr | Shipping | Aug 27, 2026 | 2 | 124 min | 62 min | 99.9% |
| Shopify | E-commerce | Aug 27, 2026 | 2 | 124 min | 62 min | 99.9% |
| Zapier | Automation | Sep 9, 2026 | 2 | 118 min | 59 min | 99.91% |
Four of the sixteen categories StatusBird tracks are represented: shipping, infrastructure, e-commerce and automation. Twelve categories, including payments, marketing, ads, marketplaces, reviews, tax, support, returns, loyalty, analytics, fulfillment and subscriptions, produced no service whose most recent incident falls in this window.
The Shopify and Deliverr overlap
Shopify and Deliverr share the same most recent incident date, August 27, the same 90-day incident count of 2, and the same 90-day downtime total of 124 minutes. The monitoring data records what was reachable and what was not, so it cannot tell you whether those two events were causally linked or simply coincident. What it can tell you is that a storefront alert and a fulfillment alert can arrive within the same hour, and that your runbook should not assume they are separate problems being handled by separate people. If you sell on Shopify and ship through Deliverr, check both live pages together: Shopify status and Deliverr status.
How long did these outages last?
Duration separates an annoyance from a revenue event, and the six services split cleanly on that measure. Squarespace averaged 10 minutes per incident over 90 days, which is short enough that many merchants would never notice. Shippo averaged 148 minutes, which is long enough for a full afternoon of label generation to stall.
The three middle cases cluster tightly. Cloudflare at 71 minutes, Deliverr and Shopify at 62 minutes, and Zapier at 59 minutes all sit near the one-hour mark. That is a useful planning number: for most of the services that broke recently, the realistic expectation is that you are working around the problem for roughly an hour, not for five minutes and not for a day. Manual fallbacks that take 20 minutes to set up are worth having. Ones that take two hours are not, for an incident of this shape.
Zapier's September 9 incident is the most recent event anywhere in the 90-day table. If your order tagging, inventory sync or internal Slack notifications route through Zapier, that is the service worth re-checking first, at its live status page.
How does this compare with the outage index history?
The monthly outage index gives the longer view:
- August 2026: 16 incidents, 40.4 hours, 9 services affected, most affected Plaid
- July 2026: 14 incidents, 22.1 hours, 8 services affected, most affected Shippo
- June 2026: 8 incidents, 37.0 hours, 8 services affected, most affected Squarespace
- May 2026: 4 incidents, 21.9 hours, 4 services affected, most affected Square
- April 2026: 20 incidents, 122.1 hours, 11 services affected, most affected AfterShip
- March 2026: 2 incidents, 8.3 hours, 2 services affected, most affected Authorize.net
August had the highest combined downtime of the last four months at 40.4 hours, and the widest blast radius since April at 9 services affected. But it was nowhere near April, which produced 122.1 hours across 11 services. Divide the hours by the incident count and the contrast is sharper: April averaged roughly 6.1 hours per incident, August roughly 2.5 hours, and July roughly 1.6 hours. Incidents are becoming more frequent and shorter, at least across this six-month stretch.
What are the three conclusions worth acting on?
1. Two services account for most of the recorded downtime
Add up the per-service downtime in the 90-day table and it comes to 4,102 minutes. Plaid at 1,548 minutes and Shippo at 1,332 minutes together account for 2,880 of those minutes, roughly 70 percent, from two services out of 84. Meanwhile 69 of the 84 services recorded zero major or critical incidents in the window. Reliability risk in e-commerce is not spread evenly across your stack; it sits in a small number of dependencies, and the useful question is whether you happen to use them.
2. Incident count is a poor proxy for pain
Plaid logged 4 incidents to Shippo's 9, yet Plaid produced more total downtime, because Plaid's average incident ran 387 minutes against Shippo's 148. When you evaluate a vendor, ask for mean time to recovery, not just an incident count or a headline uptime percentage. Shippo's 98.97% and Plaid's 98.73% look similar on paper and behave very differently in practice.
3. A quiet category is not a safe category
Payments produced no incident in the last 30 days, and Stripe, PayPal, Square, Adyen, Braintree, Klarna, Afterpay and Authorize.net all sit at 100% for the full 90 days. That is genuinely good news. It is also not a reason to drop payment monitoring, because the longest average incident in the entire table belongs to a payments service. Categories go quiet and then they do not.
What should you change this week?
- List the six services above and mark which ones you actually depend on. If Shippo generates your labels, its 98.97% is your uptime too.
- Set a one-hour fallback for each. For Zapier, that means knowing which two or three automations must be run by hand. For Deliverr or Shippo, it means knowing whether you can buy labels through a second provider account.
- Route storefront and fulfillment alerts to the same channel so a Shopify plus Deliverr overlap reaches one person rather than two.
- Read the methodology before comparing these figures with a vendor's own status history, since check interval and failure definitions change the resulting number.
If you want to know when one of these services breaks without refreshing status pages, StatusBird checks 84 e-commerce services every 2 minutes and sends alerts by SMS, email, Slack, Teams or Discord. You can set up alerts here and pick only the services you actually depend on.