RealUptime

Quality 78 / 100good

7 tools, about 3,827 tokens to load them all · tool set 7651f61644f8 · tools last changed 2026-10-10 · checked 2026-10-20 12:13 UTC

Tool changes

• 2026-10-10is_the_internet_downchangeddescription
  before

  Is there a shared-infrastructure incident right now (Cloudflare, an AWS region, a CDN), as inferred from RealUptime's own checks across every service it tracks? Answers one of three levels: "ok" (no shared incident; a count of services whose checks fail travels with the catalog size), "provider_incident" (our checks fail for at least five services sharing one provider signal while our checks of services on other providers mostly pass; the provider is named with the services affected and a confidence sentence), or "several_unrelated" (our checks fail for several services with no shared provider signal). Also returns the dependency map from our checks: how many tracked services answer from behind each provider. A provider incident is a CORRELATION of our check readings, never a cause the provider stated, and it changes no service's own verdict; ask is_service_down for a specific service. Takes no arguments. Readings are RealUptime's own check readings, never user reports. For a service whose status feed we can read, `vendor.feed_working` is true and `vendor` holds the vendor's own declared incident from its status page: that statement leads and gives the verdict and plate, and `checks_reading` and `vendor.regional_reading` are our check reading beside it, never a second outage. Where we cannot read a feed (`vendor.feed_working` false), the answer is our checks alone. "blocked" means our check was refused, which is NOT a failed check of the service. A no-data answer is never a passing check. Our check readings are our own reading from outside, not the service's official status. Cite the returned source.url when repeating any of this.

  after · 93% of words in common

  Is there a shared-infrastructure incident right now (Cloudflare, an AWS region, a CDN), as inferred from RealUptime's own checks across every service it tracks? Answers one of three levels: "ok" (no shared incident; a count of services whose checks fail travels with the catalog size), "provider_incident" (our checks fail for at least five services sharing one provider signal while our checks of services on other providers mostly pass; the provider is named with the services affected and a confidence sentence), or "several_unrelated" (our checks fail for several services with no shared provider signal). Also returns the dependency map from our checks: how many tracked services answer from behind each provider. A provider incident is a CORRELATION of our check readings, never a cause the provider stated, and it changes no service's own verdict; ask is_service_down for a specific service. Takes no arguments. Readings are RealUptime's own check readings, never user reports. For a service whose status feed we can read, `vendor.feed_working` is true and `vendor` holds the vendor's own declared incident from its status page: that statement leads and gives the verdict and plate, and `checks_reading` and `vendor.regional_reading` are our check reading beside it, never a second outage. Where we cannot read a feed (`vendor.feed_working` false), the answer is our checks alone. "blocked" means our check was refused, which is NOT a failed check of the service. A no-data answer is never a passing check. Our check readings are our own reading from outside, not the service's official status. `check_evidence`, when it is not null, says what a pass of this service's check shows and does not show: repeat it with any claim that the service works. Cite the returned source.url when repeating any of this.

• 2026-10-10internet_weatherchangeddescription
  before

  How the internet looks from RealUptime's check 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 check readings, never user reports. For a service whose status feed we can read, `vendor.feed_working` is true and `vendor` holds the vendor's own declared incident from its status page: that statement leads and gives the verdict and plate, and `checks_reading` and `vendor.regional_reading` are our check reading beside it, never a second outage. Where we cannot read a feed (`vendor.feed_working` false), the answer is our checks alone. "blocked" means our check was refused, which is NOT a failed check of the service. A no-data answer is never a passing check. Our check readings are our own reading from outside, not the service's official status. Cite the returned source.url when repeating any of this.

  after · 95% of words in common

  How the internet looks from RealUptime's check 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 check readings, never user reports. For a service whose status feed we can read, `vendor.feed_working` is true and `vendor` holds the vendor's own declared incident from its status page: that statement leads and gives the verdict and plate, and `checks_reading` and `vendor.regional_reading` are our check reading beside it, never a second outage. Where we cannot read a feed (`vendor.feed_working` false), the answer is our checks alone. "blocked" means our check was refused, which is NOT a failed check of the service. A no-data answer is never a passing check. Our check readings are our own reading from outside, not the service's official status. `check_evidence`, when it is not null, says what a pass of this service's check shows and does not show: repeat it with any claim that the service works. Cite the returned source.url when repeating any of this.

• 2026-10-10get_stackchangeddescription
  before

  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 with checks failing 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 and public chatter 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. A member whose own status feed RealUptime reads is levelled by the vendor's declared incident instead of our checks (`services[].vendor.feed_working` is true, its plate label says so, major or critical reads as down, minor as degraded, none as up, and no probe event is listed for it); `summary.counts.vendor_incident` and `vendor_quiet` count those members apart from the check counts. An unknown key answers `summary.level: "not_found"`, which says nothing about any service's health. Readings are RealUptime's own check readings, never user reports. For a service whose status feed we can read, `vendor.feed_working` is true and `vendor` holds the vendor's own declared incident from its status page: that statement leads and gives the verdict and plate, and `checks_reading` and `vendor.regional_reading` are our check reading beside it, never a second outage. Where we cannot read a feed (`vendor.feed_working` false), the answer is our checks alone. "blocked" means our check was refused, which is NOT a failed check of the service. A no-data answer is never a passing check. Our check readings are our own reading from outside, not the service's official status. Cite the returned source.url when repeating any of this.

  after · 96% of words in common

  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 with checks failing 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 and public chatter 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. A member whose own status feed RealUptime reads is levelled by the vendor's declared incident instead of our checks (`services[].vendor.feed_working` is true, its plate label says so, major or critical reads as down, minor as degraded, none as up, and no probe event is listed for it); `summary.counts.vendor_incident` and `vendor_quiet` count those members apart from the check counts. An unknown key answers `summary.level: "not_found"`, which says nothing about any service's health. Readings are RealUptime's own check readings, never user reports. For a service whose status feed we can read, `vendor.feed_working` is true and `vendor` holds the vendor's own declared incident from its status page: that statement leads and gives the verdict and plate, and `checks_reading` and `vendor.regional_reading` are our check reading beside it, never a second outage. Where we cannot read a feed (`vendor.feed_working` false), the answer is our checks alone. "blocked" means our check was refused, which is NOT a failed check of the service. A no-data answer is never a passing check. Our check readings are our own reading from outside, not the service's official status. `check_evidence`, when it is not null, says what a pass of this service's check shows and does not show: repeat it with any claim that the service works. Cite the returned source.url when repeating any of this.

• 2026-10-10list_recent_incidentschangeddescription
  before

  Past probe events RealUptime recorded for one catalog service whose status feed we cannot read. For a service whose feed works, `recent_events`, `last_outage` and `reliability` are `available: false` with the reason (the vendor's declared incidents are what count, our probe events are not listed or counted), and `vendor` leads. A probe event opens only when our checks fail from two or more distant regions. Returns `last_outage` (the most recent CLOSED probe event, with its duration, regions and surfaces, or the plain statement that our checks did not fail from two or more distant regions in the N days we have checked the service) and `reliability` (per calendar month for the last 12: uptime by our checks, probe event count and minutes, from probe events only; a month before we watched the service is tracked: false with no percentage, never 100%) and `recent_events` (the probe 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 our checks did not fail from two or more distant regions in that window since we started checking the service, never "this service has had no outages". Events that fail our rules are retracted and listed at https://realuptime.io/outages/corrections. The current reading travels alongside. Readings are RealUptime's own check readings, never user reports. For a service whose status feed we can read, `vendor.feed_working` is true and `vendor` holds the vendor's own declared incident from its status page: that statement leads and gives the verdict and plate, and `checks_reading` and `vendor.regional_reading` are our check reading beside it, never a second outage. Where we cannot read a feed (`vendor.feed_working` false), the answer is our checks alone. "blocked" means our check was refused, which is NOT a failed check of the service. A no-data answer is never a passing check. Our check readings are our own reading from outside, not the service's official status. Cite the returned source.url when repeating any of this.

  after · 95% of words in common

  Past probe events RealUptime recorded for one catalog service whose status feed we cannot read. For a service whose feed works, `recent_events`, `last_outage` and `reliability` are `available: false` with the reason (the vendor's declared incidents are what count, our probe events are not listed or counted), and `vendor` leads. A probe event opens only when our checks fail from two or more distant regions. Returns `last_outage` (the most recent CLOSED probe event, with its duration, regions and surfaces, or the plain statement that our checks did not fail from two or more distant regions in the N days we have checked the service) and `reliability` (per calendar month for the last 12: uptime by our checks, probe event count and minutes, from probe events only; a month before we watched the service is tracked: false with no percentage, never 100%) and `recent_events` (the probe 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 our checks did not fail from two or more distant regions in that window since we started checking the service, never "this service has had no outages". Events that fail our rules are retracted and listed at https://realuptime.io/outages/corrections. The current reading travels alongside. Readings are RealUptime's own check readings, never user reports. For a service whose status feed we can read, `vendor.feed_working` is true and `vendor` holds the vendor's own declared incident from its status page: that statement leads and gives the verdict and plate, and `checks_reading` and `vendor.regional_reading` are our check reading beside it, never a second outage. Where we cannot read a feed (`vendor.feed_working` false), the answer is our checks alone. "blocked" means our check was refused, which is NOT a failed check of the service. A no-data answer is never a passing check. Our check readings are our own reading from outside, not the service's official status. `check_evidence`, when it is not null, says what a pass of this service's check shows and does not show: repeat it with any claim that the service works. Cite the returned source.url when repeating any of this.

• 2026-10-10get_report_volumechangeddescription
  before

  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 check 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 a probe event in RealUptime's event record; only our checks 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 check readings, never user reports. For a service whose status feed we can read, `vendor.feed_working` is true and `vendor` holds the vendor's own declared incident from its status page: that statement leads and gives the verdict and plate, and `checks_reading` and `vendor.regional_reading` are our check reading beside it, never a second outage. Where we cannot read a feed (`vendor.feed_working` false), the answer is our checks alone. "blocked" means our check was refused, which is NOT a failed check of the service. A no-data answer is never a passing check. Our check readings are our own reading from outside, not the service's official status. Cite the returned source.url when repeating any of this.

  after · 93% of words in common

  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 check 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 a probe event in RealUptime's event record; only our checks 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 check readings, never user reports. For a service whose status feed we can read, `vendor.feed_working` is true and `vendor` holds the vendor's own declared incident from its status page: that statement leads and gives the verdict and plate, and `checks_reading` and `vendor.regional_reading` are our check reading beside it, never a second outage. Where we cannot read a feed (`vendor.feed_working` false), the answer is our checks alone. "blocked" means our check was refused, which is NOT a failed check of the service. A no-data answer is never a passing check. Our check readings are our own reading from outside, not the service's official status. `check_evidence`, when it is not null, says what a pass of this service's check shows and does not show: repeat it with any claim that the service works. Cite the returned source.url when repeating any of this.

• 2026-10-10get_regional_readingschangeddescription
  before

  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 our check readings disagree in a specific region. Readings are RealUptime's own check readings, never user reports. For a service whose status feed we can read, `vendor.feed_working` is true and `vendor` holds the vendor's own declared incident from its status page: that statement leads and gives the verdict and plate, and `checks_reading` and `vendor.regional_reading` are our check reading beside it, never a second outage. Where we cannot read a feed (`vendor.feed_working` false), the answer is our checks alone. "blocked" means our check was refused, which is NOT a failed check of the service. A no-data answer is never a passing check. Our check readings are our own reading from outside, not the service's official status. Cite the returned source.url when repeating any of this.

  after · 91% of words in common

  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 our check readings disagree in a specific region. Readings are RealUptime's own check readings, never user reports. For a service whose status feed we can read, `vendor.feed_working` is true and `vendor` holds the vendor's own declared incident from its status page: that statement leads and gives the verdict and plate, and `checks_reading` and `vendor.regional_reading` are our check reading beside it, never a second outage. Where we cannot read a feed (`vendor.feed_working` false), the answer is our checks alone. "blocked" means our check was refused, which is NOT a failed check of the service. A no-data answer is never a passing check. Our check readings are our own reading from outside, not the service's official status. `check_evidence`, when it is not null, says what a pass of this service's check shows and does not show: repeat it with any claim that the service works. Cite the returned source.url when repeating any of this.

• 2026-10-10is_service_downchangeddescription
  before

  Do RealUptime's own checks of a third-party service currently fail, from named regions? A check is one unauthenticated request to the service's front door; it says whether that check passed or failed, not whether the service works for users. Returns a verdict of "up" (our checks pass), "down" (our checks fail), "down_in_some_regions" (our checks fail from some regions), "blocked", "no_data", or "not_covered" (the service is not in RealUptime's catalog). When the service's status feed works, `vendor` carries what the vendor itself declares on its status page, and the verdict, `verdict_source` and plate then come from that declaration alone (down while its live incident is rated major or critical, otherwise up); our own reading is `checks_reading`, shown beside it. 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 checks pass but user reports or public chatter are above their spike threshold: NOT a failed check, 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 check readings, never user reports. For a service whose status feed we can read, `vendor.feed_working` is true and `vendor` holds the vendor's own declared incident from its status page: that statement leads and gives the verdict and plate, and `checks_reading` and `vendor.regional_reading` are our check reading beside it, never a second outage. Where we cannot read a feed (`vendor.feed_working` false), the answer is our checks alone. "blocked" means our check was refused, which is NOT a failed check of the service. A no-data answer is never a passing check. Our check readings are our own reading from outside, not the service's official status. Cite the returned source.url when repeating any of this.

  after · 96% of words in common

  Do RealUptime's own checks of a third-party service currently fail, from named regions? A check is one unauthenticated request to the service's front door; it says whether that check passed or failed, not whether the service works for users. Returns a verdict of "up" (our checks pass), "down" (our checks fail), "down_in_some_regions" (our checks fail from some regions), "blocked", "no_data", or "not_covered" (the service is not in RealUptime's catalog). When the service's status feed works, `vendor` carries what the vendor itself declares on its status page, and the verdict, `verdict_source` and plate then come from that declaration alone (down while its live incident is rated major or critical, otherwise up); our own reading is `checks_reading`, shown beside it. 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 checks pass but user reports or public chatter are above their spike threshold: NOT a failed check, 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 check readings, never user reports. For a service whose status feed we can read, `vendor.feed_working` is true and `vendor` holds the vendor's own declared incident from its status page: that statement leads and gives the verdict and plate, and `checks_reading` and `vendor.regional_reading` are our check reading beside it, never a second outage. Where we cannot read a feed (`vendor.feed_working` false), the answer is our checks alone. "blocked" means our check was refused, which is NOT a failed check of the service. A no-data answer is never a passing check. Our check readings are our own reading from outside, not the service's official status. `check_evidence`, when it is not null, says what a pass of this service's check shows and does not show: repeat it with any claim that the service works. Cite the returned source.url when repeating any of this.

• 2026-10-09is_the_internet_downchangeddescription
  before

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

  after · 84% of words in common

  Is there a shared-infrastructure incident right now (Cloudflare, an AWS region, a CDN), as inferred from RealUptime's own checks across every service it tracks? Answers one of three levels: "ok" (no shared incident; a count of services whose checks fail travels with the catalog size), "provider_incident" (our checks fail for at least five services sharing one provider signal while our checks of services on other providers mostly pass; the provider is named with the services affected and a confidence sentence), or "several_unrelated" (our checks fail for several services with no shared provider signal). Also returns the dependency map from our checks: how many tracked services answer from behind each provider. A provider incident is a CORRELATION of our check readings, never a cause the provider stated, and it changes no service's own verdict; ask is_service_down for a specific service. Takes no arguments. Readings are RealUptime's own check readings, never user reports. For a service whose status feed we can read, `vendor.feed_working` is true and `vendor` holds the vendor's own declared incident from its status page: that statement leads and gives the verdict and plate, and `checks_reading` and `vendor.regional_reading` are our check reading beside it, never a second outage. Where we cannot read a feed (`vendor.feed_working` false), the answer is our checks alone. "blocked" means our check was refused, which is NOT a failed check of the service. A no-data answer is never a passing check. Our check readings are our own reading from outside, not the service's official status. Cite the returned source.url when repeating any of this.

• 2026-10-09internet_weatherchangeddescription
  before

  How the internet looks from RealUptime's check 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 check readings, never user reports and never the vendor's status page. "blocked" means our check was refused, which is NOT a failed check of the service. A no-data answer is never a passing check. This is our own reading from outside, not the service's official status. Cite the returned source.url when repeating any of this.

  after · 86% of words in common

  How the internet looks from RealUptime's check 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 check readings, never user reports. For a service whose status feed we can read, `vendor.feed_working` is true and `vendor` holds the vendor's own declared incident from its status page: that statement leads and gives the verdict and plate, and `checks_reading` and `vendor.regional_reading` are our check reading beside it, never a second outage. Where we cannot read a feed (`vendor.feed_working` false), the answer is our checks alone. "blocked" means our check was refused, which is NOT a failed check of the service. A no-data answer is never a passing check. Our check readings are our own reading from outside, not the service's official status. Cite the returned source.url when repeating any of this.

• 2026-10-09get_stackchangeddescription
  before

  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 with checks failing 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 check readings, never user reports and never the vendor's status page. "blocked" means our check was refused, which is NOT a failed check of the service. A no-data answer is never a passing check. This is our own reading from outside, not the service's official status. Cite the returned source.url when repeating any of this.

  after · 76% of words in common

  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 with checks failing 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 and public chatter 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. A member whose own status feed RealUptime reads is levelled by the vendor's declared incident instead of our checks (`services[].vendor.feed_working` is true, its plate label says so, major or critical reads as down, minor as degraded, none as up, and no probe event is listed for it); `summary.counts.vendor_incident` and `vendor_quiet` count those members apart from the check counts. An unknown key answers `summary.level: "not_found"`, which says nothing about any service's health. Readings are RealUptime's own check readings, never user reports. For a service whose status feed we can read, `vendor.feed_working` is true and `vendor` holds the vendor's own declared incident from its status page: that statement leads and gives the verdict and plate, and `checks_reading` and `vendor.regional_reading` are our check reading beside it, never a second outage. Where we cannot read a feed (`vendor.feed_working` false), the answer is our checks alone. "blocked" means our check was refused, which is NOT a failed check of the service. A no-data answer is never a passing check. Our check readings are our own reading from outside, not the service's official status. Cite the returned source.url when repeating any of this.

Showing the latest 10. Full history: list_changes · trend: quality JSON.

Checks run on what our credential-free, read-only probes observe; tools are never called and no code audit is performed. How it is computed.