Model status¶
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 model status…
About these checks
Generation checks use the platform’s chat routes. Your model access may differ. Active cluster models on Engaging and AICR, including Ising, are checked every 5 minutes; external API models and other enabled routes once daily. Daily results describe the last check, not real-time availability.
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. Nemotron currently has readiness checks only because it is not connected to platform chat. 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.
Green history segments show passed checks, amber shows mixed results, red shows failed checks, and grey means no verified checks. Only the measured fraction of each day is colored; stripes indicate incomplete coverage. History begins at the first recorded 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 means a different model answered; Recovering means a request passed while an incident still awaits confirmation.
History contains recorded samples only. Missing checks remain visible. Two failed checks open an incident; two successful checks confirm recovery. For daily routes, confirmation therefore takes another daily check. 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. Prover checks use a bounded Lean prompt and require generated output, not a particular answer; they do not verify proof correctness. These checks do not verify voice, tools or long conversations.