Is the Mistral API reachable right now?
A live probe of api.mistral.ai from NetOkay’s edge, and the checks that separate a Mistral incident from a problem between you and the EU.
In short: The card below asks api.mistral.ai/v1/models without a key and expects a 401. If the host answers here but your app cannot reach it, test your own path; a long round trip to Europe makes idle and total timeouts bite sooner.
Last updated
Live probe · NetOkay Worker → api.mistral.ai
Right now, from NetOkay’s edge
Loading the latest observation of api.mistral.ai…
One keyless GET to https://api.mistral.ai/v1/models, cached for a minute per
Cloudflare location. On a healthy day this probe sees HTTP 401, the API asking for a key.
What this probe shows, and what it does not
The NetOkay Worker resolves api.mistral.ai 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.
Mistral specifics
-
API host:
api.mistral.ai, HTTPS on port 443, with an OpenAI‑style/v1/surface. Mistral’s platform is hosted in the EU, so clients far from Europe see higher round‑trip times than to US‑hosted providers. -
Streaming: Server-sent events with
data:JSON chunks and a finaldata: [DONE], compatible with OpenAI clients. Setstream: true; without it the whole completion arrives in one JSON body. - Latency and timeouts: A 150–250 ms round trip from Asia or the Americas is normal. Client libraries with short connect or read timeouts, and proxies with aggressive idle limits, fail here first even though the API is healthy.
- Error codes: 401 missing or invalid key; 422 the request body failed validation (a frequent surprise when switching from another provider’s parameters); 429 rate or spend limit; 5xx server side.
- Official status: status.mistral.ai publishes platform incidents.
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.mistral.ai.
Mistral API status FAQ
My requests time out only for Mistral. Why?
Distance. If your client sets one timeout for every provider, the EU round trip plus model latency can exceed it. Compare the probe’s response time with your client’s limit before assuming an outage.
What is a 422 from Mistral?
A validation error: an unsupported parameter, a bad message role or an unknown model name. It is an HTTP response, so connectivity is fine; fix the request body.
Is this an uptime monitor?
No. One recent observation per minute per Cloudflare location, no history. Use status.mistral.ai for incident reports.