An assistant's status page is the record of when it stopped working

Start here

Someone who has built a habit, or a workflow, around an AI assistant eventually hits the moment it simply does not respond. The useful question in that moment is not philosophical, it is operational: is this a known, tracked outage, and what does the vendor say happened? Every major vendor keeps a public status page for exactly this, and reading one turns a vague frustration into a specific, timestamped record.

What the documents say

OpenAI's status page, retrieved 16 September 2026, reported all systems operational at the time of reading and published rolling uptime figures for recent months: APIs at 99.93%, ChatGPT at 99.64%, Codex at 100%, and its FedRAMP offering at 100%, figures the page frames as recent history rather than a permanent guarantee. Anthropic's status page (the anthropic.com address now redirects here) listed two specific recent incidents at the time of reading: one on 16 September 2026 describing 'issues with Google Play subscriptions' for Android sign-ups, resolved after Google 'confirmed their own platform issue,' and an earlier incident on 3 September 2026 describing 'elevated errors for multiple models,' naming the Mythos, Fable and Opus model families, resolved after a fix was deployed and monitoring confirmed recovery. Google's Workspace status dashboard listed a closed incident affecting Google Drive lasting 37 minutes, with its last update posted the same day the page was read. All three pages record incidents by name, date and, for Anthropic and Google, a short cause description, rather than showing only a green or red current-status indicator.

Check this

The direct check when an assistant seems broken is to open its vendor's status page before assuming a personal connection problem or a permanent change: a listed, dated incident confirms a known outage, and the page's own update timestamps show whether a fix is already in progress. The absence of a listed incident, conversely, points the problem back toward a local cause, since the vendor's own page would show a known outage if one existed.

What holds and what fails

Status pages hold as an accurate, vendor-published record of incidents the company itself chooses to disclose, timestamped and named as such; they do not capture problems too small or localized for a vendor to classify as an incident, and uptime percentages describe recent history, not a promise about the next outage. Relying on a single assistant for a task with no fallback plan is a risk these pages document indirectly, by showing that outages recur across every major vendor, not a specific claim any one page makes.

• Bookmark the status page for any assistant a workflow depends on, and check it first during an outage.
• Read the incident's stated cause and resolution, not just the current green or red indicator.
• Keep a fallback method for any task where an assistant being briefly unavailable would actually matter.

A status page cannot prevent an outage, but it turns 'is it just me' into a checkable fact, and the record of past incidents is itself a reason to have a plan for the tool being unavailable.