How We Detect ChatGPT Outages

How IsChatGPTDown.chat detects ChatGPT outages: data sources, monitoring methodology, connectivity-latency calculation, uptime math, severity definitions, and independent disclosure.

How We Detect ChatGPT Outages

This page documents exactly how IsChatGPTDown.chat decides whether ChatGPT is operational, degraded, partially down, or fully down. Our goal is transparency — users, journalists, and developers relying on this site should be able to understand every status label they see.

1. Data Sources

We combine multiple attributed signals into a single status answer:

  • Official OpenAI status — pulled from the status.openai.com Statuspage v2 JSON API (components feed). We evaluate the components that make up the consumer ChatGPT product separately from developer/API components.
  • Independent reachability probe — direct GET requests against chatgpt.com and chat.openai.com from our infrastructure, with TLS verification and redirect handling. This proves connectivity, not that authenticated conversations succeed.
  • Official incident history — every incident from OpenAI’s official incidents.json API, stored by its stable official incident id with clean name, timestamps, severity, and the full official update timeline. The result is published as our ChatGPT outage history archive.
  • User reports — aggregated one-click reports from visitors over a rolling 15-minute window, used only as a supporting signal.
  • Regional probesnot currently deployed. Until real regional probes exist, regional availability is shown as “Unavailable” and does not raise our confidence.

2. Polling Interval & Freshness

At the time of this review, the monitor targets a 30-second interval when the hosting scheduler runs on time. Each completed result is stored with the exact time it was taken; missed intervals remain gaps and are not counted as uptime. The Current Live Configuration section below is the source of truth if this setting changes. We apply strict freshness rules:

  • Fresh — within one monitoring interval plus a short grace period.
  • Delayed — beyond the grace period; confidence is capped at medium.
  • Stale/unavailable — beyond the configured stale-data threshold. Stale data is never shown as operational, and we display a clear “live monitoring data is temporarily unavailable” state instead.

3. Component Mapping (Consumer ChatGPT vs API)

OpenAI’s status feed lists many components. We map them to the consumer ChatGPT product (conversations, GPTs, voice mode, login, file uploads, search, image generation, etc.) or to developer/API services (Responses, Chat Completions, Embeddings, Fine-tuning, Batch, Codex API, etc.). An API-only incident never marks consumer ChatGPT as down, and API-only incidents do not appear under “ChatGPT Active Outages”. Developer-side incidents are reported on OpenAI API status, and the full picture across every OpenAI service is on OpenAI status.

4. Independent Reachability Check

We perform direct HTTP probes against the ChatGPT web endpoints. A 2xx/3xx response indicates reachability. A 401/403 for an anonymous request means the host is reachable but challenged — this confirms connectivity only, not that signed-in conversations work. A 429 is flagged as degraded; 5xx and connection errors are flagged as down.

5. Confidence Rules

  • High — multiple fresh independent signals agree.
  • Medium — signals are fresh but incomplete or mildly inconsistent, or data is only slightly delayed.
  • Low — only one fresh source is available.
  • Unavailable — required signals are stale.

6. Connectivity-Latency Calculation

On each probe run we measure connectivity latency — the time between the request going out and the response arriving from chatgpt.com. This measures network reachability, not the time required for ChatGPT to generate a response. We store every measurement and surface the average and peak over the displayed chart window. When the latest data is stale we do not present an old latency value as current.

7. Observed Uptime, Coverage & Missing Data

Observed uptime is calculated from distinct 30-second monitoring intervals, not raw database rows or chart points. An interval is covered when it contains at least one valid stored overall_monitor_status result. Multiple results in the same interval count once; if any valid result is non-operational, that interval is non-operational for uptime. For a qualifying window, observed uptime is calculated as operational covered intervals / all covered intervals.

We publish an uptime value only when at least 99% of the expected intervals are covered, gap validation is available, and no continuous missing-data gap exceeds 300 seconds. Missing intervals are neither operational nor down. If any gate fails—or coverage cannot be verified—the site shows Unavailable and the API returns null. The API’s coverage.percent is monitoring coverage, not uptime. Both fields are exposed in our free status API so you can verify them yourself.

Observed uptime is this site’s derived measurement of stored overall-monitor intervals. It is not an OpenAI SLA or an official OpenAI uptime figure. In the API, official_status reflects OpenAI’s public status feed, independent_check reflects this site’s reachability probe, and the top-level status is this site’s combined classification.

8. Incident Severity Definitions

  • Minor — user-reported or edge-case problem; the service remains broadly operational.
  • Degraded — service responds but slower than normal (latency above the 2000 ms threshold) or with increased error rates.
  • Partial outage — some features or regions fail while others continue to work.
  • Major outage / Down — service is broadly unreachable or OpenAI has officially declared a major outage.
  • Maintenance — planned downtime communicated in advance by OpenAI.

9. False-Positive Handling

A single failed probe does not trigger an outage. We require either an official OpenAI confirmation, three or more independent probe failures, or a user-report spike with high confidence before marking a major outage. Each probe carries a confidence weight — the engine combines them and emits a confidence level (low, medium, or high) alongside the status.

10. Known Limitations

Our monitoring has a bounded view of reality. A user experiencing local DNS issues, ISP routing problems, or account-specific throttling may see ChatGPT as down while our monitor reports operational. Our reachability probe cannot verify that signed-in conversations succeed — only that the service is reachable. We do not claim to detect outages before OpenAI; the official OpenAI status page is authoritative for official incident communications.

11. User-Report Aggregation, Spam Filtering & Privacy

User reports are one-click and require no login. The application stores the selected issue type, submission time, and a salted one-way anti-abuse hash derived from the IP address and browser user agent. This pseudonymous fingerprint supports deduplication and rate limiting; it is not used to create accounts or behavioral profiles. Report records are scheduled for automatic deletion after 30 days. Hosting and security providers may separately process IP addresses in technical logs as described in our Privacy Policy.

12. Independence & Correction Policy

IsChatGPTDown.chat is independently operated and is not affiliated with, operated by, or endorsed by OpenAI. Our reachability-probe results and derived classifications are independent observations; official component and incident data are sourced from OpenAI and linked for verification. If you spot an error in our data, please tell us via the contact page and we will correct it.

Monitoring Changelog

  • July 2026 — Rebuilt incident ingestion to use OpenAI’s official JSON incident API; added strict data-freshness rules (stale data is never shown as operational); separated consumer ChatGPT from developer/API status.
  • August 2026 — Changed uptime to distinct 30-second intervals, exposed coverage diagnostics, and fixed publishing gates at 99% coverage with a maximum five-minute continuous gap.

Last reviewed: August 2026.

Current Live Configuration

Check interval
Every 30 seconds
Official OpenAI status polling
Enabled
Independent HTTP probe
Enabled
Incident scrape
Every 30 minutes (last run: 2026-09-11 20:40:10)
Log retention
90 days
Degraded-latency threshold
2000 ms (connectivity latency above this is flagged as degraded)
Homepage result refresh
Every 30 seconds (display only; new checks run per the interval above)