System status¶
Current checks for our models, API and website.
Subscribe to updates
Follow confirmed incidents, recoveries and scheduled maintenance in your feed reader: RSS · Atom. Updates appear when an incident is confirmed; delivery timing depends on your reader.
Loading service status…
About these checks
API. Authenticated model discovery, Chat Completions, Claude-compatible Messages and Responses are measured separately. Protocol checks use a permitted model and test streaming and tool-result continuity. When discovery finds no available permitted model, protocols remain unknown and generation is not attempted. Once an available model is selected, a failed request or timeout counts as a failed API check. The model used by each protocol check appears in its details.
Website. Public page and configuration checks measure website reachability. Model generation and API protocol checks have their own rows.
Availability and coverage. The 90-day charts show only recorded observations. Grey time has not been verified. Availability percentages describe observed time, with measurement coverage shown in the details; a short measurement history does not establish 90 days of uptime. Older model history records check counts rather than continuous availability.
Generation checks use the platform’s chat routes. Your model access may differ. Each tracked model is checked every 5 minutes.
Serving readiness is checked separately through each cluster endpoint’s health and model identity. Server ready means the model server passed those checks; it does not prove chat generation. Not in chat means the model is absent from the monitoring account’s picker; expand the row for its separate server result. Models remain listed during outages.
The badge shows the latest check; each history bar combines recorded checks for one UTC day. A model can be Online after recovery while earlier failed checks remain in its history. Green portions show passed results, red shows failed results, amber fill shows different or unverified models/routes, and grey means unmeasured time. Mixed days show each result in proportion; the portions summarize totals, not the order of events. The main chart uses measured seconds, while the expanded recorded-check chart uses sample counts. A fallback records a different or unverified model/route; it is separate from a failed response. A colored edge makes a recorded result visible even when coverage is tiny; amber edges summarize mixed or unverified results. An edge does not mean the whole day was measured. The fill shows proportional coverage, and stripes indicate incomplete coverage. Recorded-check history begins at the first check. Passing samples do not establish uptime during gaps.
Online and Offline describe whether the platform returned a valid generated completion at the last check. A timeout, unavailable deployment, upstream error or invalid completion is a failed check. Offline does not mean the host machine is powered off. Unknown means the check could not establish availability, including missing access, quota limits or stale measurements. Fallback records a different or unverified model/route; Recovering means a request passed while an incident still awaits confirmation. Offline, stopped and not-in-chat entries are listed last; other entries retain their catalogue order.
History contains recorded samples only. Missing checks remain visible. Two failed checks open an incident; two successful checks confirm recovery. The first failed check is still visible as Offline before an incident is confirmed. The monitor's internal degraded state can mean an unconfirmed failure or recovery; the table translates it into the last request result, with incident confirmation shown separately in the expanded details.
Response models are reported by the platform. An alias can conceal a fallback. Model generation checks do not verify voice, tools or long conversations. The separate API rows include hourly tool-result continuation checks.