What a vendor status page can tell you
Use vendor incident reports alongside endpoint measurements and your own request data. Each source answers a different part of the investigation.
CheckUpstream Team
1 min read
Published
A status page tells you what a vendor has published about its service. It is useful evidence, with a particular scope. It does not describe every customer request, and an absence of reported incidents does not prove that your integration is working.
Read the scope of the report
Check the affected products, regions, and incident period. Follow the updates rather than relying on the overall colour of the page. A resolved incident report also does not establish that your queued work has finished or that your app has recovered.
Keep the report’s timestamps separate from the times at which you observed errors. They describe different events and may answer different questions in a retrospective.
Compare it with your own requests
Use your application’s error and latency records to establish whether a relevant operation is failing. A vendor incident may not affect your region or product. Your requests may also fail when the vendor has published no incident.
Independent probes add another observation: whether a particular endpoint responded from a particular location and time. A probe is not a complete test of the vendor’s service or of your own account.
Keep the limits visible
On CheckUpstream, current status, incident history and front door check counts, and SLA terms answer separate questions. Check coverage varies. Missing checks are unknown, and check counts alone do not establish credit eligibility.
The methodology explains those boundaries. Use the source and coverage information when deciding how much weight to place on a number.
Editorial correction, September 6, 2026: unsupported detection-delay estimates and claims of universal measurement coverage have been removed from this article.