How long your vendors take to admit an outage

How this is measured

The two timestamps

Detected is the first of StatusBird's two-minute checks that read a service as major or critical. Acknowledged is the moment the vendor posted an incident on its own status page, read from the timestamp Atlassian Statuspage writes when an incident is published. That timestamp is set at post time and cannot be edited afterwards, which is why it, and not the vendor's own claim about when the trouble started, is used here.

For the services polled through a Statuspage endpoint, both numbers come from the vendor. This is not a claim that StatusBird saw an outage before the vendor did. It is narrower and easier to check: the vendor's own dashboard went red at one time, and the vendor wrote something about it at another, later time. A status page can turn a component red without anyone opening an incident, and often does.

Services with no machine-readable incident feed are not graded. Their outages still appear on their status pages, but there is nothing published to compare them against, and a vendor should not score badly because StatusBird cannot read its feed.

The grade

The mean acknowledgement lag over a rolling 90 days, on the same thresholds StatusGator uses, so the two can be read side by side. An outage the vendor never acknowledged counts as 240 minutes, which is also StatusGator's convention.

What counts as an outage

Major and critical readings only, the same rule as every other availability figure StatusBird publishes. Several vendors report minor degradation almost continuously, and counting that would bury the signal. An outage is a run of major or critical checks; a single missed poll does not split one in two.

An incident the vendor posted up to an hour before the dial moved still counts as acknowledging that outage. One posted more than a day later does not. A long-running incident the vendor left open from a previous week is not treated as acknowledging a new outage that happens to fall inside it.

Checkout exposed

StatusBird publishes no revenue figure here. A logged-in Business account with Shopify revenue connected sees one extra column, computed from its own store's average hourly revenue; it is an estimate, not a measurement, and every assumption behind it is listed here:

• The checkout exposure figure is shown only to a logged-in Business account with Shopify revenue connected, and it uses that store's own average hourly revenue, the same figure the alert emails use. StatusBird publishes no revenue figure for anyone else and assumes no median store.
• That revenue is spread flat across the hour. StatusBird has no hour-of-week revenue curve, so it does not apply one.
• Each service carries a checkout factor: how much of checkout its outage puts at risk. Payments, e-commerce platforms and subscriptions are 1.0. Infrastructure, tax, shipping, fulfillment and marketplaces are 0.25. Marketing and ads are 0.10. Reviews, support, analytics, loyalty, returns and AI vendors are 0.
• Where the vendor's own incident title or component list names checkout, payments, orders or the storefront, that incident is counted at 1.0 whatever its category. Where it names only back-office surfaces such as the admin or reporting, it is counted at 0.10 or its category factor, whichever is lower.
• Exposed minutes are the minutes the outage ran while unacknowledged, never more than the outage itself lasted. An outage the vendor never acknowledged is exposed for its whole length.

Read it as "roughly this much was flowing through checkout while nobody had said anything", not as a loss figure. Some of that revenue arrives late rather than never, and a store that spotted the outage another way lost nothing to the silence.