How vendor reliability is worked out

Each vendor page with a status page carries a short record: what that vendor declared on its own status page over the last 180 days. It is the vendor’s own account, read by us, not a measurement of the service. This page says what we read, how the figures are calculated, and when we give no figure at all.

What we read

• Our poller reads each vendor’s public status page every five minutes, and has done since March 2026. It uses the page’s machine-readable feed (Atlassian Statuspage, incident.io, Instatus, Better Stack, status.io, the AWS, Google Cloud and Azure feeds, Salesforce Trust, and Adyen’s and PayPal’s own status feeds), never the look of the page.
• It records the page’s overall state: operational, degraded, partial outage, major outage or maintenance. The severity is the vendor’s own word for it. A Statuspage “major” incident is our partial outage; “critical” is our major outage.
• History is kept for 400 days. Each published figure covers the last 180 days.
• The figures are recalculated about once an hour. Each block shows the date it was calculated. A record older than 7 days is not shown.

Coverage: time we could not see is unknown, never “up”

A stretch counts as observed only when we read the page and know its state. These are unknown and are left out: time before we started monitoring the vendor; any stretch when our own poller did not run; any time the page could not be read (an error, a timeout, a changed format); any stretch in which the page changed state while we could not read it, because we cannot tell when the change happened; any day with no successful read on record; and any time before we have evidence that we could read the page at all, such as the months before a broken monitor was fixed. Coverage is the observed share of the 180 days.

The parts, shown beside the score

Outage-free time (declared)

One minus the share of observed time the page declared an outage. A major outage counts in full; a partial outage counts half, because on a whole-page indicator it usually means one component.

Outages per 30 days

How many outages (partial or major) began in the window, per 30 observed days. Two outages separated by 15 minutes or less of recovery are one outage, not two. An outage that was already going when the window opened is counted in the time but not as a new outage.

Median time to resolve

The median length of the outages we saw start and end. The median, not the average, so one long incident does not define a vendor. An outage whose start or end we did not see is left out, because its length is unknown.

Trend

Outages that began in the earlier half of the window against the later half. “Similar” when the two differ by one or less. Only shown when both halves are at least 80% observed.

Degraded (shown, not scored)

Hours per 30 days the page read “degraded”. It is not in the score: on most pages one slow component turns the whole page amber, and some components stay amber for weeks, so degraded time says more about how a page is built than about the service.

Maintenance

Planned, announced work. It never counts against a vendor.

The day strip

Beside the score, and in place of it when there is none, each vendor page draws the 180 days as one bar per day (UTC). A red bar is a day on which the page declared an outage, partial or major. A light orange bar is a day with degraded time and no outage. A grey bar is a day with no outage declared; planned maintenance counts as that. A hatched stretch is time we did not observe: a day is drawn as not observed when more than half of it was unread, unless an outage or degraded time was seen in the part we did read, because hiding that would hide an incident. Hover a bar for its date and, on red and orange days, the hours. The strip shows days, not incidents; the figures above it count incidents. It is not drawn for a vendor under review, or one whose page publishes no severity.

The score

A number from 0 to 100 that blends the first three parts. The parts are always shown beside it, so nobody has to take the blend on trust.

score = 100 × (0.5 × A + 0.3 × F + 0.2 × R)

A = (outage-free share − 99%) ÷ 1%, kept between 0 and 1
F = 1 ÷ (1 + outages per 30 days)
R = 1 ÷ (1 + median hours to resolve ÷ 4), or 1 when no outage was timed

Worked example: 99.9% outage-free, one outage a month and a four-hour median give 0.5 × 0.9 + 0.3 × 0.5 + 0.2 × 0.5 = 0.70, a score of 70. A vendor that declared no outage at all scores 100; its degraded hours are what the page shows next.

When there is no score

• Not enough status history yet: less than 80% of the 180 days observed, or fewer than 60 observed days.
• No incidents declared: the page recorded no change of any kind in the observed time. We say exactly that, “self-reported”, and give no score: a quiet page can be a rarely updated one.
• No severity published: some status pages cannot say how bad a problem is, only that there is one. Outage figures cannot be calculated for them.
• Under review: one disruption lasted more than 7 days. That is far more often a component nobody cleared than a week-long outage, so no score is given until it has been checked.

Read with care

• Self-reported. A vendor that posts little looks better than one that posts everything. The record measures what was declared, not what happened.
• Pages differ. A whole-page indicator goes amber when any one of its components does, so a vendor listing 80 components reads amber more often than one listing 3. A cloud provider’s feed is filtered to the one service we map. Salesforce’s feed marks every Salesforce product for any incident in any of them. The block says which kind of page it is when that matters.
• Shared pages. Some products share one status page (several Salesforce clouds, for example). Their records are one source, not independent evidence, and the block names the others.
• Excluded components. When one component on a page stays in the same state for weeks and would dominate the record, we can stop counting it. The block names any component we excluded. It applies from the day it was excluded; earlier history is not rewritten.
• No rankings. We do not rank vendors by this record or compare one vendor’s with another’s on these pages. Figures from different kinds of status page are not like for like.

Corrections

If a figure looks wrong, or your status page has moved, write to hello@martechstackbuilder.com with the vendor and the page address. We fix the monitor; we do not edit the record by hand.