An Uptime Basics free service-status page and a provider's official status page answer different questions.
The Uptime Basics page asks: Can an independent external check reach this selected public URL?
The official provider page asks: What does the provider know about its own services, components, regions, maintenance, and incidents?
Use both sources when investigating a problem.
What independent monitoring can observe
An independent check can identify:
- DNS lookup or TLS connection failures;
- timeouts;
- unsuccessful HTTP responses;
- slow responses from the selected endpoint; and
- short interruptions visible outside the provider's network.
It is useful because it does not depend on the provider's internal monitoring or your local device and internet connection.
What it cannot observe
A free service page checks one public URL on a fixed 15-minute schedule. It cannot directly see:
- the provider's internal servers, queues, databases, or private APIs;
- every product component or customer account;
- every geographic region or internet route;
- planned maintenance known only to the provider;
- application behavior that requires signing in or running JavaScript; or
- the provider's investigation and incident communications.
An Up result means the selected public URL answered successfully. It is not a guarantee that every feature is working for every user.
What an official status page can provide
The provider may publish:
- component-level status;
- affected products and regions;
- maintenance windows;
- incident acknowledgements and investigation updates;
- estimated restoration information; and
- a provider-authored incident history.
However, an official page may be updated after automated detection or human confirmation. It can also report broad platform health while an issue affects only a route, location, account group, or public endpoint.
Why the two pages can disagree
Both results can be accurate within their scope:
| Situation | Independent page | Official page |
|---|---|---|
| Public homepage fails but core APIs remain healthy | May show failed checks or Down | May show operational |
| One internal component fails while the monitored URL works | May show Up | May report an incident |
| Regional routing problem | Depends on the monitoring path | May report a regional issue |
| Provider blocks automated requests | May show failed or ambiguous checks | May show operational |
| Very recent outage or recovery | May wait for the next check or cache refresh | May update earlier or later |
| Problem is limited to your device, ISP, DNS resolver, or account | May show Up | May show operational |
The timestamps matter. Compare the latest independent check time with the time of the official incident update and your own observation.
How to investigate responsibly
- Reload the Uptime Basics page and note Current Status, Last checked, HTTP status, latency, and Recent History.
- Open the provider's official status page from its own website or support documentation.
- Test from another network or device when possible.
- Check whether the problem affects one feature, account, region, or the entire service.
- Contact the provider when official or account-specific assistance is required.
Do not treat either page as proof by itself. Independent monitoring provides external evidence; the official page provides provider-controlled operational context.
Independence and affiliation
Uptime Basics free service-status pages are independently operated and are not affiliated with, endorsed by, or controlled by the monitored providers unless explicitly stated.
Provider names and URLs identify the service being checked. The provider remains the authoritative source for its maintenance, security, support, and incident communications.