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. The inbox card this monitor raises is built on the alert primitive described in inbox-alerts.md, and how desktop notifications are delivered and silenced is covered by notifications-and-silence.md.