1. Start with the service's own outage page, not a forum search
Every tracked service on realuptime outages has a page at realuptime.io/outages/<service>, showing our own probe reading from each of the ten regions we check from, refreshed on that service's own cadence (as often as every 2 minutes for the most-searched services). This is a measurement, not a crowd tally: it answers whether the service actually failed to respond to an independent request, not whether other people are also complaining right now.
2. Read the per-region readings, not just the headline
If every region we check shows down, that is evidence the problem is on the service's side, not yours. If some regions are down and others are clean, that is a regional outage: a bad deploy or a CDN edge failing in one place while the rest of the world is fine, which is exactly the failure mode a single-location status page collapses into one green badge. If our regions are clean but you personally cannot reach the service, the fault is more likely between you and the service, not the service itself: your DNS resolver, your ISP's route, or a VPN or corporate proxy sitting in the middle.
3. Rule out your own network before you blame the vendor
Try three things, in order: (1) switch DNS resolvers (1.1.1.1 or 8.8.8.8 instead of your ISP's default) and reload, since a stale or poisoned DNS answer only breaks the service for you; (2) turn off any VPN or corporate proxy and try again on a different network entirely, for example your phone's cellular data, since a VPN exit node or an ISP-level route can be down while the service itself is fine; (3) if the service is a website you operate yourself, run it through the free live checker at realuptime.io/tools/is-it-down, which makes one fresh request server-side, outside your own network path, so a result there is not affected by anything wrong on your end.
4. Know what a probe can see, and what it honestly cannot
A probe reading proves a public, unauthenticated endpoint answered or did not; it does not prove every feature behind a login works, and it never logs in or holds an account with any service it checks. For most services we check a landing or status page, which is a real reachability signal but not a full functional test; a smaller number of services also expose a genuine public API we check functionally, and each service's own page says plainly which kind of check it gets. A consumer app that walls its real functionality behind sign-in cannot be checked more deeply than that from outside, and no honest external monitor can tell you whether your login or your checkout page works without either credentials or your own instrumentation inside the app.
5. Do not mistake a block for an outage, or a report spike for a measurement
A reading of "awaiting data" or "blocked" means our probe's request was refused or filtered by the service's own automated-traffic defenses, not that the service is down: a browser on a home connection can get a normal page from the exact same endpoint at the same moment. That is why we record it as its own state rather than folding it into down. Likewise, a spike in user reports next to a clean probe reading is shown as its own amber state (reachable, reports elevated) rather than overruled either way: reports are people saying something, a probe reading is a measurement, and the two are never merged into one number.
6. Go further: the live hub and the methodology behind it
realuptime.io/outages lists every tracked service's current reading in one place, and realuptime.io/outages/internet answers the broader question (a shared-infrastructure incident across many services at once, inferred from our own probes, never from social chatter). For the full, honest account of what a status-line check can and cannot prove, read the methodology page linked below: it is the same page every service's own outage reading links back to.
Go deeper
The full reference lives in the docs: Outage tracker methodology. Error codes named above are each explained in the error-code reference.