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

Every team integrating Mistral AI 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. Mistral runs on a custom single-page app (not 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 status.mistral.ai, 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 status.mistral.ai

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 Mistral health checks report green through an incident.

How Granular Is the Component List?

Mistral is the outlier of the five: status.mistral.ai is not an Atlassian Statuspage, so none of the /api/v2/* conventions you have wired up for other providers apply. There is no component list to poll and no indicator field to read. What Mistral does publish is an incident RSS feed.

Treat /history.rss as Mistral's API. Everything else on that domain is a rendered page, not data.

The 200-OK Trap Nobody Catches

This is the single most expensive thing to know about Mistral's status page: requesting https://status.mistral.ai/api/v2/status.json returns HTTP 200 — with an HTML Page not found document as the body. The single-page app serves a catch-all route rather than a 404. If you copied a Statuspage poller from your Groq or Cohere integration and pointed it at Mistral, your health check is passing on a 404 page and has never once told you the truth. Assert on the parsed payload, never on the status code alone.

Polling It Correctly

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

import { XMLParser } from 'fast-xml-parser';

// status.mistral.ai is NOT an Atlassian Statuspage. /api/v2/status.json
// returns HTTP 200 with an HTML "Page not found" body — a health check
// that only asserts res.ok will pass forever. Parse the RSS feed instead.
const MISTRAL_FEED = 'https://status.mistral.ai/history.rss';

async function mistralRecentIncidents({ withinHours = 24 } = {}) {
  const res = await fetch(MISTRAL_FEED, { signal: AbortSignal.timeout(5000) });
  const body = await res.text();

  // Guard: if we got HTML back, we hit the SPA catch-all, not the feed
  if (!body.trimStart().startsWith('<?xml')) {
    throw new Error('Mistral status feed returned HTML, not RSS');
  }

  const items = new XMLParser().parse(body)?.rss?.channel?.item ?? [];
  const cutoff = Date.now() - withinHours * 3600_000;

  return [items].flat().filter((i) => new Date(i.pubDate).getTime() > cutoff);
}

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 Mistral 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 Mistral 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.mistral.ai/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 Mistral Down? Outage Checking Guide, and for the error-code side of the same question, the Mistral API Error Codes Explained.

Subscribing to Mistral Incidents

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

Where to Send Traffic During a Mistral 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 Mistral Guides

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