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

Every team integrating Perplexity 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. Perplexity runs on a minimal hosted status page, 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.perplexity.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.perplexity.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 Perplexity health checks report green through an incident.

How Granular Is the Component List?

Perplexity publishes exactly three components: Website, API and Computer. There is no per-model breakdown, no separate search-index component, and no split between the consumer product and the developer API beyond that one API row. Statuses come back uppercase (OPERATIONAL), which is a different casing convention from the lowercase Atlassian values — a string comparison ported from another provider will never match.

Read the API component specifically. If you are building on api.perplexity.ai, a green Website tells you nothing — and the consumer app going down does not imply your integration is affected.

status.json Returns 404 Here — summary.json Doesn't

Perplexity's page answers Statuspage-shaped paths selectively: /api/v2/summary.json and /api/v2/components.json both return 200 JSON, but /api/v2/status.json — the path most integration snippets on the internet use — returns 404. The second gotcha is casing: component statuses are OPERATIONAL, not operational. Both bugs fail closed and quiet, which is the worst combination: your health check either errors on every poll or never matches, and either way it stops being a signal.

Polling It Correctly

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

// Perplexity's page answers /api/v2/summary.json and components.json,
// but /api/v2/status.json — the path most snippets use — returns 404.
// Statuses are also UPPERCASE, unlike Atlassian's lowercase values.
const PPLX_COMPONENTS = 'https://status.perplexity.com/api/v2/components.json';

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

  const { components } = await res.json();
  const api = components.find((c) => c.name === 'API');

  if (!api) throw new Error('Perplexity API component missing from status page');

  // Compare case-insensitively — 'OPERATIONAL', not 'operational'
  return { healthy: api.status.toUpperCase() === 'OPERATIONAL', raw: api.status };
}

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

Subscribing to Perplexity Incidents

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

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

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