Groq Status Page Guide: Endpoints, Components and What It Won't Tell You

Every team integrating Groq eventually wires the status page into something — a health check, a dashboard tile, a Slack alert. Most of those integrations are subtly broken, because "the status page" is not one standard thing. Groq runs on Atlassian Statuspage, and that choice decides which endpoints exist, what shape the payload is, and what the page is capable of telling you at all.

This guide is the practical version: the exact paths on groqstatus.com, what each one returns today, the ones that return a success code with a useless body, and the gap between what the page reports and what your users are experiencing.

The Endpoints on groqstatus.com

Verified against the live page. Note the rows marked with a warning — those are the paths that look like they work and do not, and they are the reason so many Groq health checks report green through an incident.

How Granular Is the Component List?

Groq is the most granular status page of the five major inference providers: every hosted model is its own component. A component list 20 entries long means llama-3.1-8b-instant can be degraded while qwen/qwen3-32b is untouched, and the top-level indicator will happily say All Systems Operational through it.

If you poll only status.json on Groq you are throwing away the most useful thing the page publishes. Poll components.json and match on the exact model string you have pinned in config.

Groq's Status Page Lags Model Decommissioning

Groq retires hosted models faster than any other major inference provider, and a decommissioned model is not an incident — it simply stops appearing in the component list. So the failure mode is silent: your requests start returning 404 model_not_found, the status page stays green, and nothing on groqstatus.com ever mentions it. Diff the component list against your pinned model names on a schedule; a model that vanishes from components.json is a deprecation notice you missed.

Polling It Correctly

Roughly 40 lines, no dependencies beyond a fetch, and it fails loudly rather than silently when the page shape changes.

const GROQ_STATUS = 'https://groqstatus.com/api/v2/components.json';

// Poll the components, not the top-level indicator — Groq lists every
// hosted model separately, so a single model can degrade while the
// page-level indicator still reads "All Systems Operational".
const MODELS_I_DEPEND_ON = ['llama-3.1-8b-instant', 'qwen/qwen3-32b', 'API'];

async function groqHealth() {
  const res = await fetch(GROQ_STATUS, { signal: AbortSignal.timeout(5000) });
  if (!res.ok) throw new Error(`Groq status page returned ${res.status}`);

  const { components } = await res.json();
  const mine = components.filter((c) => MODELS_I_DEPEND_ON.includes(c.name));

  // A model that disappeared entirely is a decommission, not an outage
  const missing = MODELS_I_DEPEND_ON.filter(
    (m) => !components.some((c) => c.name === m),
  );

  return {
    degraded: mine.filter((c) => c.status !== 'operational').map((c) => c.name),
    decommissioned: missing,
  };
}

Two habits worth keeping regardless of provider: put a hard timeout on the request — a status page that hangs should never hang your health check — and assert on a parsed field rather than on the HTTP status code. Every trap in the table above passes an res.ok check.

Why the Status Page Is the Last to Know

A status page is a communications artifact, not a monitoring system. The sequence during a real Groq incident is almost always the same: requests start failing, internal alerts fire, an engineer confirms scope, someone with page access writes an update, and only then does the indicator move. That chain has humans in it, and it runs in minutes rather than seconds.

The second structural problem is aggregation. A page-level indicator answers "is Groq broadly healthy", which is not the question you have. Your question is whether your requests, to your model, from yourregion, are succeeding — and partial degradation that hits a slice of traffic routinely never moves the indicator at all.

1. Detect on your own metrics. Error rate and p99 latency against https://api.groq.com/openai/v1 move within seconds.
2. Attribute with the status page. Once you know something is wrong, the page tells you whose problem it is.
3. Check the component, not the headline. The indicator can read operational while the component you depend on does not.
4. Confirm with a second key. If a different key on a different account succeeds, you are looking at quota, not an outage.
5. Fail over on the second consecutive failure. One error is noise; two in a row is an incident.

For the full outage playbook see our Is Groq Down? Outage Checking Guide, and for the error-code side of the same question, the Groq API Error Codes Explained.

Subscribing to Groq Incidents

Three channels, in ascending order of how quickly they reach you:

Where to Send Traffic During a Groq Incident

Fallbacks only help if they are configured before the incident, and if the fallback does not share a status page with the thing that just broke. Each of these runs independently:

Frequently Asked Questions

Related Groq Guides

• Is Groq Down? Outage Checking Guide
• Groq API Error Codes Explained
• Groq API Status Alerts
• Groq API Monitoring Guide
• Groq API Outage History
• Groq Status Guide
• Best Status Page Tools 2026
• API Monitoring Tools for Startups