Is the Groq API reachable right now?
A live probe of api.groq.com from NetOkay’s edge, and why a fast provider makes your own network’s behaviour easier to spot.
In short: The card below asks api.groq.com/openai/v1/models without a key. Groq’s edge answers 403 to keyless automated requests within milliseconds; the host is up if you see it. Because Groq streams tokens quickly, a stream that arrives “all at once” for you almost always means buffering on your path.
Last updated
Live probe · NetOkay Worker → api.groq.com
Right now, from NetOkay’s edge
Loading the latest observation of api.groq.com…
One keyless GET to https://api.groq.com/openai/v1/models, cached for a minute
per Cloudflare location. On a healthy day this probe sees HTTP 403 within milliseconds, an
edge refusal of a keyless automated request.
What this probe shows, and what it does not
The NetOkay Worker resolves api.groq.com through Cloudflare DNS, opens a TLS connection and sends one GET without credentials, following no redirects. Any HTTP status, including 401, 403 or 405, means the host answered. Several providers refuse keyless automated requests at their edge with a 403 in a few milliseconds; that still proves DNS, TLS and the front door, but it is the provider’s edge answering, not necessarily the API application behind it. The result is one observation from one Cloudflare location, refreshed at most once a minute and never stored.
It cannot see your API key, quota, region, model availability or account state, and it does not travel your network path. A healthy probe and a failing application are compatible; the sections below are for that case.
Groq specifics
-
API host:
api.groq.com, with the OpenAI‑compatible surface under/openai/v1/. Clients built for OpenAI usually only change the base URL and key. -
Streaming: OpenAI‑style server-sent events:
data:JSON chunks ending withdata: [DONE]. Groq’s chunks arrive fast enough that a proxy which buffers a few kilobytes before flushing can turn a stream into a single burst at the end. - What fast delivery reveals: If the homepage SSE check reports events arriving close together, and Groq responses also arrive in one block, the buffering is on your path, not at Groq. The idle stream check tells you whether that path also drops silent connections.
-
Error codes: 401 or 403 key missing
or invalid; 429 rate limit, with
retry-afterwhen Groq expects you to wait; 503 capacity. All are HTTP responses from a reachable host. - Official status: groqstatus.com publishes incidents for the API and console.
Reachable here but failing for you?
- Run the homepage checks from the network where the app fails. The 30‑second idle stream shows whether something on your path closes silent connections, which is what a long model pause looks like to a proxy.
- Read the idle result. Closed during the silence points at a proxy, gateway or NAT idle limit under 30 seconds. Start and done arriving together points at response buffering. Both have fixes in the streaming guide.
- Compare environments. If the browser passes and a container, server or agent fails, compare the public IP each one uses, then run the CLI from the failing environment against api.groq.com.
Groq API status FAQ
Groq is supposed to be fast. Why is my first token slow?
Time to first token includes your own path: DNS, TLS, any corporate proxy and the request queue at Groq. Compare the response time in the probe above with what your client measures; a large gap is on your side.
I get 403 from the probe and from my app. Same cause?
Not necessarily. The probe sends no key, so 403 is expected. If your app also gets 403 with a key set, check the header name and that the key belongs to the right organization.
Does this page tell me whether Groq is down globally?
No. It is one observation from one Cloudflare location, refreshed at most once a minute. Use groqstatus.com for incidents.