Groq status

How we check Groq

We watch api.groq.com from all five of our probe regions, every 2 minutes. A region that sees a failure does not make this page say "down" on its own: a second region has to agree first, the same confirmation rule every YoPingMe monitor uses.

We watch the API host applications send inference requests to and pin the response an unauthenticated request receives, rather than expecting a 2xx. The console and marketing site are served separately and can look entirely healthy while the inference API is refusing or slowing traffic, which is the failure that reaches your users.

What is Groq?

Groq runs inference on custom hardware designed for the job, and speed is the product. Where general-purpose accelerators are optimised for training and adapted for serving, Groq's architecture targets the generation of tokens one after another, which is what makes the difference noticeable in an interactive application. Teams choose it when the response time of a model is a user-facing feature rather than an implementation detail.

That focus shapes what an incident looks like. For an application built around fast responses, a degradation that leaves every request succeeding but doubles the time to produce them is a genuine problem, even though nothing has failed and no status page will mark it. This is the reason the per-region response times above sit next to the up-or-down verdict rather than behind it. A monitor that only asks whether a request succeeded would report a perfect day through exactly the incident most likely to affect a product whose value is speed.

Rate limiting is the most common cause of errors that get mistaken for outages. Limits are enforced per model and per account, across both request counts and token throughput, and a batch job or a traffic spike can consume the allowance quickly. The response is a 429 with headers describing what remains, which is the API behaving correctly and telling you so. Applications that treat every non-200 as an outage will report one; applications that read the headers will back off and continue.

Model availability is the second thing to separate from platform health. Hosted inference providers add and retire models on their own schedule, and a request naming a model that has been deprecated fails while everything else works. The error is specific and names the model, but integrations that log a generic failure hide that detail, which turns a one-line configuration change into an outage investigation.

Finally, it is worth thinking about what your application should do when inference is unavailable. Products that call a model in the request path have made that model a hard dependency of the feature, and often of the page. A fallback that degrades to a simpler behaviour, a queued retry, or even an honest message beats a spinner that never resolves, and the decision is much easier to make in advance than during the first incident.

Frequently asked questions

Is Groq down right now?

Check the board above; it reflects our own probes against Groq's API from all five of our regions, refreshed every couple of minutes and confirmed across two regions before this page would call it down.

I am getting 429 errors from Groq. Is that an outage?

No, a 429 is rate limiting and means the API answered you. Limits apply per model and per account across requests and tokens, and a burst of traffic or a batch job can exhaust them while the service is entirely healthy. The response headers report your remaining allowance, which tells you immediately whether you are being limited or something is actually wrong.

My requests are slower than usual. Does that count as downtime?

Not as downtime, but it is worth watching, which is why the response times above are shown alongside the up or down state. Inference latency varies with model, prompt length, and current load, and a degradation that never fails a request can still break a product built around fast responses. A page that only tracked availability would call that a perfect day.

Does a model being unavailable mean Groq is down?

No, and this is a common source of confusion. Models are added, deprecated, and occasionally taken out of service individually, so a request naming a model that no longer exists returns an error while every other model responds normally. The error names the model, and the current model list in Groq's documentation is the place to confirm.

How is this page different from Groq's own status page?

Theirs reports what Groq's engineers have confirmed and published, including per-component detail. This page reports what our probes see from the outside, on a fixed schedule, independent of when or whether an update gets posted. During an incident, the two together are more useful than either alone.