The expensive part of an outage is usually the hour after it ends, when queues drain unevenly and nobody checks which records never arrived. Start by writing down the exact start and end time of the outage in your store's timezone, then work through six systems in a fixed order: payments, order routing, email and SMS, subscriptions, tax, and post-purchase apps.
This guide is the cleanup pass, not the first-response pass. It assumes the vendor is back up and you now need to find out what silently failed while it was down.
Why does the cleanup matter more than the outage itself?
During an outage, most systems fail loudly: a customer sees an error, a webhook returns a 500, an app shows a red banner. After recovery, failures go quiet. A payment sits in an authorized-but-not-captured state. An order exists in Shopify but never reached your shipping app because the webhook retry window expired. A Klaviyo flow skipped the profiles that entered while the API was unreachable, so those buyers never got an order confirmation or a shipping notification.
The gaps are also long enough to matter. Over the 90 days ending September 08, 2026, the average major incident on Plaid ran 387 minutes, and Shippo averaged 148 minutes across 9 major or critical incidents. These figures come from StatusBird's independent monitoring, which checks each service every 2 minutes. Six hours of missing payment-method links or unbought shipping labels is not something you notice by refreshing a dashboard.
What do you need before you start?
Three things, in writing, before you touch anything:
- The outage window with minutes, not hours. Pull it from your monitoring alert history or from the service's reliability page, for example Shippo's reliability history. If your only source is the vendor's own status page, treat the posted start time as later than reality, because acknowledgements often trail the first failure.
- The window converted to your store's timezone. Vendor status pages and API logs usually publish in UTC, while your Shopify admin order list filters in store local time. Convert once, write both versions down, and use the local version for every admin filter.
- A single reconciliation note. One document or one ticket. Every finding goes in it: order numbers, counts, dollar amounts recovered, actions taken. You will want this for vendor support, for any service credit request, and for the next time it happens.
Which systems should you check, and in what order?
1. Payments: authorizations, captures, and pending states
Open Shopify admin, go to Orders, and filter by Payment status is Pending, then again by Payment status is Authorized, restricted to the outage window plus two hours on either side. Any authorization that never captured is money you have not collected, and gateway authorizations expire on a fixed schedule, so check your processor's expiry rule and capture or void deliberately rather than letting them lapse. Then filter Payment status is Unpaid and look for orders where the customer completed checkout but the charge failed at the final step; those get a manual invoice or a recovery email, not silence.
If the outage hit a buy now, pay later provider or a bank-linking service, check for half-finished checkouts. A failure in a service like Plaid does not usually block a card sale, but it does block the account-link step, and those sessions abandon without an order record. Compare checkout sessions started against orders created for the window.
2. Order routing to fulfillment and shipping apps
Export the full order list for the outage window as CSV from Shopify admin, then export the same window from your shipping or 3PL system and compare order numbers. This two-export diff is the only reliable way to catch orders that never crossed the boundary. In ShipStation, use the store's manual refresh action to force a re-pull rather than waiting for the next scheduled sync. In a 3PL portal, resubmit the missing orders individually and confirm each one appears with the correct service level, because a re-push after an outage sometimes defaults rates to the cheapest available method.
3. Email and SMS: what queued, what dropped, and what will double-send
Two opposite risks. First, flows that skipped: open your email platform's flow analytics for the outage window and look for a recipient count near zero on your order confirmation and shipping notification flows. Those customers need a manual send, and order confirmations are the priority because their absence generates support tickets within hours.
Second, flows that queued and will now fire late: if a campaign or flow was mid-send when the platform recovered, check that a promotional send from yesterday is not about to land as if it were new. Pause any flow whose timing no longer makes sense, fix the copy, then resume. Do this before you touch anything else in the platform, because a stale send goes out fast once the backlog clears.
4. Subscriptions and billing retries
Subscription billing runs on a schedule, so an outage that overlaps your billing hour produces a batch of failed charges that look identical to genuine card declines. In your subscription app, filter for failed charges inside the outage window and retry them manually as a group, before the dunning sequence sends a payment-failed email to customers whose cards were fine. Also check that no subscriber was cancelled by an automatic churn rule triggered by those artificial failures.
5. Tax calculation
If a tax service was unreachable, some carts may have completed with a fallback rate or with no tax applied. Filter orders in the window for a tax total of zero in a taxable jurisdiction, list them in your reconciliation note, and decide whether to absorb the difference or correct it. This one is small in volume and large in audit risk, so record the decision either way.
6. Post-purchase apps: tracking, returns, reviews, loyalty
These fail quietly and get discovered by customers. Check that tracking numbers pushed to your tracking platform for shipments created during the window, that return requests submitted during the outage exist in your returns tool, that review request jobs for orders in the window were queued, and that loyalty points accrued. For each, the test is the same: pick three orders from inside the window and trace them end to end by hand.
7. Ads and analytics
Do not judge campaign performance using data from the outage window. Annotate the window in your analytics tool and in your reporting spreadsheet so that next month's review does not treat a monitoring gap as a conversion rate collapse. If your storefront itself was down, check whether any campaign kept spending against a broken landing page and note the amount.
How long should you budget for the pass?
Match your effort to the length of the outage. Average incident duration varies widely by service, which tells you how deep the queue is likely to be:
| Service | Major incidents in 90 days | Total downtime | Average incident |
|---|---|---|---|
| Plaid | 4 | 1,548 min | 387 min |
| Shippo | 9 | 1,332 min | 148 min |
| ShipStation | 1 | 166 min | 166 min |
| Klaviyo | 1 | 146 min | 146 min |
| Shopify | 2 | 124 min | 62 min |
All figures above are from StatusBird's independent 2-minute monitoring over the 90 days ending September 08, 2026, and the measurement rules are described on the methodology page. A 60-minute storefront outage is usually a 20-minute cleanup. A six-hour payments dependency outage is a half-day job across two people.
What goes in the reconciliation note?
Keep it to one screen: the service name, the window in both UTC and store time, your source for the window, total orders in the window, count and value of payments recovered, count of manual email or SMS sends, count of orders re-pushed to fulfillment, any tax or discount corrections, and one line on what you would automate next time. Vendor support asks for exact timestamps and affected record IDs, and a note written the same day answers that in one reply instead of three.
What can you fix before the next one?
Three changes cut the cleanup pass down materially. Turn on your shipping or 3PL system's alerting for failed order imports so gaps surface within the hour rather than at the next export. Set your subscription tool's dunning delay long enough that a short billing-hour outage does not fire payment-failed emails immediately. And save the CSV export view you use for the order diff, so the first step of the next cleanup is one click instead of ten minutes of filter building. The outage index gives you a sense of the monthly cadence: August 2026 recorded 16 major or critical incidents across 9 services, so it is worth doing this work once properly.
Knowing the exact minute an outage started and ended is what makes this pass fast, and that is easier when something is watching the services you depend on rather than reconstructing it later. StatusBird checks around 84 e-commerce services plus your own storefront every 2 minutes and sends alerts by SMS, email, Slack, Teams, or Discord, and you can set it up here if that is useful for your store.