SOURCES & METHODOLOGY

What the status means.

Reports, observations and missing data are kept distinct.

Official reports

The directory includes 56 AI services across assistants and search, coding, creative media, model APIs, inference and GPU cloud, and vector databases. 37 have configured automatic sources, alongside 11 general services. This is an editorial selection, not a measured popularity ranking or complete industry inventory. We save provider reports and do not independently confirm AI service availability.

Claude and GitHub summaries include components, incidents and maintenance. Other compatible summary endpoints can omit event lists; omission is shown explicitly. OpenAI's collected endpoint currently supplies component statuses without incident or maintenance lists. ChatGPT and API summaries are derived separately from fixed, verified component IDs; new or missing IDs require review. Their availability is not a claim about any particular model, tier or account.

Copilot, v0, Replicate, Workers AI and AI Gateways are read from their specific components on shared provider pages. The parent page's overall indicator and unrelated incidents are not assigned to these products. A missing selected component prevents a new report from being saved.

Hugging Face, Together AI, Modal, Runpod and Qdrant use the public Better Stack JSON format. Referenced resources and report updates must be present. Resolved reports are excluded even when their end time is absent. Resource update times are not invented from the page timestamp. DeepInfra's published service and model statuses are provider observations; responses marked stale by that provider are rejected. Incident and maintenance details are not imported by this adapter.

Vercel, Supabase and Cloudflare have complete platform report views. Vercel and Cloudflare also have separate product-specific views. Notion and Resend use their verified current status domains; their collected summaries omit incident and maintenance lists. Slack’s version 2 current API supplies status and incident records, with affected feature names in updates; it does not supply a complete component matrix. Scheduled Slack records are kept separate without inventing a maintenance window.

Stripe uses its verified new status domain for component reports, incidents and maintenance. Auth0’s official page supplies embedded JSON for ten public production-region headlines; scripts are not executed, and private cloud, tenant health, incident detail and maintenance are not imported. Missing regions or changed page identity reject a new report. AWS Health supplies public event records in its currently verified UTF-16 big-endian format. Services, regions, updates and numeric provider codes are retained, but those codes are not interpreted as severity or resolution. Its aggregate remains neutral and does not establish account health or overall AWS availability.

Google Cloud’s public incident feed is checked against its own product catalog. Ended and future incidents do not become current incidents. With no active public incidents the summary remains neutral; it does not describe Personalized Service Health or independently establish a project’s availability. Provider product and location names are retained with incident updates.

The Gemini source is the Google Workspace Gemini incident feed, checked against its official product catalog. Ended, future and unrelated incidents do not become current Gemini incidents. With no active incidents, the label is “No reported incidents,” not an assertion that Gemini is operational. The latest Gemini incident update is distinct from collection time; a feed with no Gemini incidents has no published Gemini update time.

Grok / xAI imports fourteen verified service headline cards without executing scripts. Live charts and incident detail are not imported. DeepSeek imports the structured active-change summary from its public page; no changes reported leaves overall availability unknown. Neither page supplies a verified publication time for these collected fields. fal uses its version 3 summary and seven verified components; both responses must validate, and missing notice detail or publication times remain missing. CoreWeave uses the Status.io public API with verified status codes, provider components and locations; current and future maintenance are separate.

Midjourney uses the production JSON feed linked by its own official status page. Its service headlines are separate from Fast and Relax waiting-time estimates. Waiting-time color codes are not service outages or independent latency measurements. The provider feed timestamp is retained, and reports older than fifteen minutes or more than thirty seconds in the future are rejected.

Google Cloud AI filters the public cloud incident feed to 23 verified Vertex product IDs. Other Google Cloud incidents are excluded; missing selected products reject a new report. This view is separate from Gemini app and Gemini API / AI Studio. Codex collects only the Codex in ChatGPT Desktop component in OpenAI's report, which does not establish CLI, IDE extension or cloud task availability.

Gemini API, Google AI Studio and Google Cloud AI are separate from this Gemini app feed. Gemini API / AI Studio has its own official status page; automated collection of that page is not implemented. “Official page only” means a linked status page without automatic collection. “Not connected” means no status data; any linked product website is labelled as a website.

Collection and freshness

The worker checks each configured source every 120 seconds, with up to 15 seconds of jitter. Pages read saved data and refresh every 30 seconds while visible. Manual refresh also reads saved data.

A valid collection becomes stale after 6 minutes. Its last known report remains visible with a stale warning. Collection time is when we received and validated the data. Source update time is supplied by the provider or explicitly labelled as the latest incident update; an unchanged source timestamp does not by itself mean collection is stale.

Each collection has a 10-second deadline and each response is limited to 512 KiB. Gemini and Google Cloud each require both their own fixed product catalog and incident feed to pass validation before a report is saved. Collection failures back off, up to one hour, taking a parseable Retry-After value into account. A failure is recorded separately and never changes the provider’s report into an outage.

Unknown status values stay unknown. Missing incident or maintenance fields are labelled as not provided. Scheduled future maintenance is shown separately and does not count as a current outage. A missing incident in a feed does not establish its full history or independently confirm recovery.

Daily history and coverage

The directory shows the last seven UTC dates; service details offer thirty or seven days. Each point represents the most severe saved state that day, separately from current status. Green means a normal report or passing check, yellow means degraded performance or a check being rechecked, red means a reported outage or confirmed failing check, and blue means ongoing maintenance. Gray covers missing or inconclusive observations; the explanation identifies the reason.

A half-filled point marks incomplete coverage or an unfinished day. Today's dashed ring means the day is still in progress. Known status coverage counts interpretable records over the complete day, or elapsed time today. It is record coverage, not measured uptime.

Saved states are bounded by the next observation and their existing freshness limits: six minutes for official reports and fifteen minutes for checks. Probe history reuses the consecutive-failure and recovery rules. Collection failures are counted separately and never become outage states. Durations describe saved report or check states, not exact incident durations. Dates before our first observation stay gray; we do not import or claim complete provider incident history.

Regional observations

Independent probe agents check the GitHub public homepage and read metadata for one public repository through the GitHub API. Checks use IPv4 HTTPS, validate the certificate and expected response content, and record name resolution, connection, TLS, response-header and total timing. A passing homepage check does not establish that sign-in, Git operations or Actions work. A public API read does not establish that authenticated operations work.

The selected resolver is shown with each node. Agents can use the system resolver or Cloudflare DNS over HTTPS. The latter does not test the system resolver and may select different destination addresses. Addresses in private or special ranges are rejected; targets are fixed, validated public addresses are pinned for the request, and redirects are not followed.

Each agent checks two fixed connectivity controls, operated by Cloudflare and Mozilla. At least one must pass before target failures can count toward confirmation. If neither passes, results say “Probe connectivity uncertain.” This is a limited connectivity test, not proof that the node or every network path is healthy.

Checks run every 5 minutes, with up to 15 seconds of jitter. The first failure says “Rechecking failure”; two consecutive failures confirm a failing check at that node. Recovery from a fresh confirmed failing check requires two successes; after a stale gap, a successful check starts a new baseline. Confirmation requires observations and receipts at least 4 minutes apart, with no gap of 15 minutes or more. Denied access, rate limits, redirects and rejected target addresses are inconclusive and do not confirm a service failure.

Observations and heartbeats become stale after 15 minutes. Stale checks do not retain a current passing or failing badge. Observation time is when the agent finished a check cycle; receipt time is when the server accepted it. Missing reports, collection failures and service failures remain distinct.

Business-target checks run on independent nodes. The center collects official reports and receives results; it does not probe business targets. Unverified locations do not appear in regional history. Ashburn, Frankfurt and Tokyo require real remote nodes; registration alone cannot establish coverage. Node location and network are configured by the operator, not verified automatically. We do not infer regional reachability from a global official report, vote different nodes into a global status, or infer an outage cause.

View actual coverage

Dependencies and causality

No verified upstream dependency records are published yet. A provider incident alone does not establish which application it affected or the cause of a user’s problem.

Free access and minimal measurement

Status queries are free and do not require an account. Email notifications are planned; this version does not send mail or collect email addresses.

We record service page visits, official source link clicks and optional feedback using a random identifier held in this browser tab’s sessionStorage. We do not store IP addresses, emails or the full User-Agent in these records. Automatic data refreshes do not count as new visits. Known bots are filtered on a best-effort basis.

Development events are marked internal. Data is stored in the database configured by the operator. Automated retention cleanup has not yet been implemented; public deployment requires a retention policy and its enforcement.