RealUptime

Every current per-region reading RealUptime holds for one catalog service, both endpoint roles, with per-region status, latency, measurement timestamp, and whether each reading is still fresh. This is the regional detail behind is_service_down: use it to answer "is X down in Europe" style questions, or to show that reports and measurements disagree in a specific region. Readings are RealUptime's own probe measurements, never user reports and never the vendor's status page. "blocked" means our probe was refused, which is NOT a confirmed outage. A no-data answer is never a healthy answer. Cite the returned source.url when repeating any of this.

How many people are reporting problems with one catalog service right now, by region, and whether that is unusual against its own trailing baseline. Returns a per-region count of reports and distinct reporters for the most recent five-minute window, a spike verdict of "spike", "normal" or "insufficient_data", and RealUptime's own probe reading for the same regions so the two signals can be compared without being merged. These are UNVERIFIED user reports: no account, no verification, and the region on a report is chosen by the person filing it. Report volume never opens, extends or closes an outage in RealUptime's event record; only probe measurements do. "insufficient_data" means there are not enough reports to say anything, which is NOT the same as reports being normal, and must never be quoted as "no problems reported". Readings are RealUptime's own probe measurements, never user reports and never the vendor's status page. "blocked" means our probe was refused, which is NOT a confirmed outage. A no-data answer is never a healthy answer. Cite the returned source.url when repeating any of this.

One "my stack" page: a named set of RealUptime-tracked services, each with the SAME plate level its own page shows (down / partially_down / degraded / partially_degraded / blocked / no_data / partially_unverified / up, with label and clause), plus the stack's roll-up: `summary.headline` ("2 of 6 services down or degraded"), the worst member level, and counts by state. Pass `stack`, the stack's slug (from its URL, https://realuptime.io/outages/stack/<slug>) or id. Stacks are built at https://realuptime.io/outages/stack or from a Monitor dashboard; there is no list endpoint, a caller must hold the key. User reports, public chatter and the vendors' own status pages are not read for a stack (those signals are published as null), so `reachable_reports_elevated` never appears here; a member's own page still shows it. An unknown key answers `summary.level: "not_found"`, which says nothing about any service's health. Readings are RealUptime's own probe measurements, never user reports and never the vendor's status page. "blocked" means our probe was refused, which is NOT a confirmed outage. A no-data answer is never a healthy answer. Cite the returned source.url when repeating any of this.

How the internet looks from RealUptime's probe regions right now (https://realuptime.io/outages/internet-weather): for each of the ten regions (iad = US-East, sjc = US-West, fra = Europe, nrt = Asia-Pacific, ord = US-Central, yyz = Canada, lhr = UK, sin = Southeast Asia, syd = Australia, gru = South America), the latest hour's p50/p95/p99 response time across the ~195 public services in RealUptime's outage catalog, the region's 7-day baseline, and a `state` of "normal" / "slower" (only after three consecutive hours over 1.5x the baseline, clearing at 1.25x) / "no_baseline" / "no_data", plus a 24-hour sparkline and the last 30 days per day. This is a picture of a REGION's vantage point over many services, NOT any one service's latency and NOT customer monitoring traffic (which never enters this aggregate). `coverage.typical_claim_allowed` says whether the record is old enough (30 days) to call a figure "typical for the region"; until it is, say "compared with the last 7 days" instead. Takes no arguments. Readings are RealUptime's own probe measurements, never user reports and never the vendor's status page. "blocked" means our probe was refused, which is NOT a confirmed outage. A no-data answer is never a healthy answer. Cite the returned source.url when repeating any of this.

Is a third-party service currently down, as measured by RealUptime's own probes from up to four named regions? Returns a verdict of "up", "down", "down_in_some_regions", "blocked", "no_data", or "not_covered" (the service is not in RealUptime's catalog). Also returns `plate`, the public page's headline: one level from down / partially_down / degraded / partially_degraded / reachable_reports_elevated / blocked / no_data / partially_unverified / up, with its label and the sentence under it. "reachable_reports_elevated" means our probes answer but user reports or public chatter are above their spike threshold: NOT an outage, and never to be quoted as one. Pass `region` (iad = US-East, sjc = US-West, fra = Europe, nrt = Asia-Pacific) to ask about one region only. Readings are RealUptime's own probe measurements, never user reports and never the vendor's status page. "blocked" means our probe was refused, which is NOT a confirmed outage. A no-data answer is never a healthy answer. Cite the returned source.url when repeating any of this.

Is there a shared-infrastructure incident right now (Cloudflare, an AWS region, a CDN), as inferred from RealUptime's own probes across every service it tracks? Answers one of three levels: "ok" (no shared incident; a count of services probe-confirmed down travels with the catalog size), "provider_incident" (at least five services sharing one measured provider signal are probe-confirmed down while services on other providers are mostly up; the provider is named with the services affected and a confidence sentence), or "several_unrelated" (several services down with no shared provider signal). Also returns the measured dependency map: how many tracked services answer from behind each provider. A provider incident is a measured CORRELATION over probe-detected outages, never a cause the provider confirmed, and it changes no service's own verdict; ask is_service_down for a specific service. Takes no arguments. Readings are RealUptime's own probe measurements, never user reports and never the vendor's status page. "blocked" means our probe was refused, which is NOT a confirmed outage. A no-data answer is never a healthy answer. Cite the returned source.url when repeating any of this.

Past outages RealUptime detected for one catalog service. Returns `last_outage` (the most recent CLOSED outage our probes detected, with its duration, regions and surfaces, or the honest "no outage recorded in the N days we have measured this") and `reliability` (per calendar month for the last 12: uptime %, outage count and minutes, from probe-detected events only; a month before we watched the service is tracked: false with no percentage, never 100%) and `recent_events` (the probe-detected outage events of the last 90 days, most recent first, at most 10, the open one included: for each, started_at, ended_at (null while open), duration, peak_level (down / partially_down), the regions and surfaces involved with their per-facet legs, and detected_by, which is always "probe"). An empty list travels with window_days and tracking_since and means no event in that window since we started measuring the service, never "this service has had no outages". The current reading travels alongside. Readings are RealUptime's own probe measurements, never user reports and never the vendor's status page. "blocked" means our probe was refused, which is NOT a confirmed outage. A no-data answer is never a healthy answer. Cite the returned source.url when repeating any of this.