---
title: Anthropic outage alerts (API status monitor)
---

# Anthropic outage alerts (API status monitor)

## What it is

When Anthropic itself has an outage, your Claude sessions start failing with API errors and it looks like something is wrong with _your_ setup. The **Anthropic API status monitor** removes the guesswork: Omniscio watches Anthropic's official public status page in the background and tells you — automatically — when an Anthropic incident is what's breaking your sessions, then tells you again when it's fixed. You never have to open status.anthropic.com yourself.

It is **on by default**. Turn it off at **Settings → Notifications → Anthropic outage alerts** (`anthropicStatusMonitorEnabled`).

## Where to find it

It is on by default, so there is nothing to set up — the alerts simply arrive in your
Inbox and as a desktop notification on their own. The one control is the off switch at
**Settings → Notifications → Anthropic outage alerts** (`anthropicStatusMonitorEnabled`).

## How it behaves

### What you see during an incident

1. **One inbox card** — "Anthropic API issue: _(incident name)_" listing the affected components, plain-language reassurance ("it's their outage, not a problem with your setup"), and a note that the card clears itself. Its primary button is **View status page**, which opens Anthropic's live status page in your browser — shown alongside the usual "Start session" button, which now appears on every alert (View status page is the useful action here — a new session can't fix their outage and would likely fail during one). The card updates in place as the incident evolves; it never duplicates.
2. **One desktop notification (silent)** — a toast that appears only when the card is first created. It does **not** play an alarm sound: an Anthropic outage isn't something you can fix, so it's a quiet heads-up, not an error chime. Steady failures, incident updates, and app restarts during the same incident never re-notify.
3. **A note inside failing sessions' chats** — any session that fails with an Anthropic API error while the incident is active gets one line: _"Anthropic is reporting an active incident (…) — this failure is likely on their end, not your setup."_ One note per session per incident, so retries can't spam a conversation.
4. **The all-clear** — once Anthropic marks the incident resolved (confirmed by two consecutive clean checks, so a mid-incident blip can't fake recovery), the inbox card archives itself and one "Anthropic incident resolved" notification fires.

If you dismiss the card mid-incident, it stays dismissed — even across an app restart. Only a genuinely _new_ incident (one that started after your dismissal) raises a fresh card.

### How it detects incidents

Two signals, combined:

- **Baseline poll** — every 5 minutes Omniscio fetches Anthropic's public status feed (`https://status.claude.com/api/v2/summary.json` — the JSON behind status.anthropic.com, which redirects there). During an active incident it polls every 60 seconds so the all-clear lands fast.
- **Reactive check** — the moment any of your sessions actually fails with a transient Anthropic API error (the same detection that drives Omniscio's silent retry), the monitor checks the status page _immediately_ instead of waiting for the next 5-minute tick. Forced checks are rate-limited (at most one per minute) so a burst of failing sessions can't hammer Anthropic's status page. Only sessions running on an Anthropic account trigger this — an OpenAI/codex session's error never does.

**Relevance filtering**: only incidents affecting the **Claude API** or **Claude Code** components count. An incident that only affects the claude.ai website (or Console/Cowork) does not fail CLI sessions, so it never alarms you. As insurance against Anthropic renaming components, a site-wide major/critical incident with no component detail still counts.

**Never a false alarm about the feed itself**: if Omniscio can't reach the status page (your network is down, a CDN blip, an unrecognized response), it just keeps its last known state and retries — the status page being unreachable is a different problem with a different warning (the offline banner).

### FAQ

**Does it cover other providers (OpenAI, etc.)?** Not yet — v1 is Anthropic only, because Claude sessions are what Omniscio predominantly runs. The module layout (`provider-status/`) leaves room for siblings.

**Does it cost anything?** No. It's a tiny unauthenticated GET to a public CDN-backed feed — no AI tokens, no account usage.

**Why didn't I get a notification for an incident on the status page?** Most likely it only affected claude.ai (the website) — those are filtered out on purpose. If it affected the API and you'd previously dismissed the card for that same incident, the dismissal is respected.

## For agents

### Under the hood (for agents with repo access)

- Service: `src/main/services/provider-status/anthropic-status-monitor.ts` (60s registered tick, adaptive fetch cadence, single-flight); pure parsing/decisions in `anthropic-status-classifier.ts` (fixture-tested).
- Reactive nudge seam: `armApiErrorRetry` in `src/main/process/ndjson-turn-error-detection.ts` → host `nudgeAnthropicStatusCheck` → the monitor (provider-gated via `usesAnthropicAccount`).
- Inbox card: the standard alert primitive with dedupKey `anthropic-api-status` (`src/shared/alert-features/anthropic-status-alert.ts`); the "View status page" carve-out lives in `AlertInboxViewer`.
- In-chat notes ride `emitNotableSystemMessage` (kinded `notable-system`, survives the status-noise filter).
- Gates: `anthropicStatusMonitorEnabled` (default on, re-read each tick), inert under `AMC_INSTANCE_ID` (e2e/sandbox), kill switch `AMC_DISABLE_ANTHROPIC_STATUS_MONITOR=1`.
- Contract with test-locked invariants: `.claude/memory/contracts/anthropic-status-monitor-contract.md`.

## Related

The wider provider-status and alert family is covered by [provider-status-alerts.md](provider-status-alerts.md). The inbox card this monitor raises is built on the alert primitive described in [inbox-alerts.md](inbox-alerts.md), and how desktop notifications are delivered and silenced is covered by [notifications-and-silence.md](notifications-and-silence.md).