How we count front door checks

A vendor record on CheckUpstream’s reliability pages reports our checks as counts, for example: "Front door reachable in 2,850 of 2,860 checks with a clear answer, last 30 days, checked every 15 minutes from a single CheckUpstream location." Each count names the host it checked. It does not describe the whole vendor or the success of requests from your application.

Updated September 27, 2026: this article previously explained a measured availability percentage. We no longer publish one. The explanation below describes the counts that replaced it.

What a check does

A front door check sends one request to a documented vendor endpoint and compares the answer with what that endpoint is documented to send. An unauthenticated HTTP 401 can be the documented answer, so a passing check does not always mean HTTP 200.

We run the checks every 15 minutes from a single location. The counts cover the last 30 days.

What the two numbers mean

• Reachable: checks whose answer matched the documented response.
• With a clear answer: checks that answered clearly, either way.

For an illustrative example, a vendor checked every 15 minutes for 30 days gets 2,880 checks. Suppose 2,850 matched, 10 failed and 20 gave no clear answer. The record reads "reachable in 2,850 of 2,860 checks with a clear answer" and says separately that 20 more checks gave no clear answer and are not counted.

Checks without a clear answer

Some results say nothing about the vendor. A failed check with an HTTP 4xx response, including a rate limit or an authentication error, describes our request. A check also has no clear answer when its configuration needs review, when the response does not match its content marker, when the failure is attributed to our monitoring network, or when an initial failure has not been corroborated. The methodology lists the categories.

These checks are counted separately and added to neither number. When no clear answer has arrived for 24 hours, the record says so instead of presenting older counts as current.

Why there is no percentage

Checks 15 minutes apart cannot see disruptions shorter than that. A two-minute failure between two checks leaves no trace in the counts. Dividing one count by the other and rounding to three places would claim a precision about the vendor that the checks do not have. The counts say what was observed, and the window and cadence beside them say what could not be.

Why incident reports stay separate

A vendor report describes the products, regions and incident period the vendor disclosed. It does not measure your requests, and vendors differ in how broadly and how often they report incidents. We show those records as what the vendor says, in the vendor’s words and with its timestamps, and do not turn them into a figure.

Keep application impact and claims separate too

Use your own request records to establish whether the operation your customer attempted succeeded. A vendor report and a front door check can help an investigation, but neither proves what happened in your application.

An SLA claim depends on the applicable product, contract, measurement method, exclusions and filing requirements. Our check counts do not establish eligibility. Read the vendor’s recorded terms and verify them against the linked original document.

The methodology explains these boundaries across the product.