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

Every team integrating Cohere 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. Cohere 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 status.cohere.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 status.cohere.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 Cohere health checks report green through an incident.

How Granular Is the Component List?

Cohere publishes the deepest component list of the five — roughly 30 entries — and, unusually, it separates its endpoint families as well as its models. Generation (the Command series), embeddings and the Rerank models each appear independently, so an embeddings degradation is visible without any impact on chat traffic.

If your RAG pipeline uses Cohere for both embeddings and reranking, watch both components. They fail independently, and the page-level indicator will not move for either one.

The Model You Pinned Is Not the Component You're Watching

Cohere versions its model names into the component list — command-a-03-2025, command-a-plus-05-2026, command-r-08-2024, command-r7b-12-2024. Teams routinely alert on a substring like command-r, which matches several unrelated components at once and produces noise on every one of them. Worse, when you upgrade the pinned model in your code, the alert keeps watching the old component and goes quiet on the one you now depend on. Match on the exact, full component name and update it in the same commit as the model bump.

Polling It Correctly

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

const COHERE_COMPONENTS = 'https://status.cohere.com/api/v2/components.json';

// Cohere separates endpoint families, not just models: a degraded
// 'embeddings' component does not move the page-level indicator and
// does not imply anything about your Command traffic.
const WATCHED = ['command-a-03-2025', 'embed-v4.0', 'rerank-v4.0-fast'];

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

  const { components } = await res.json();

  // Exact match, never substring — 'command-r' matches four components
  return WATCHED.map((name) => {
    const c = components.find((x) => x.name === name);
    return { name, status: c ? c.status : 'MISSING_FROM_STATUS_PAGE' };
  });
}

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

Subscribing to Cohere Incidents

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

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

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