Provider Status Monitoring & Incident Warnings

[mulhamna]

Feature Request: Provider Status Monitoring & Incident Warnings

Problem

When a provider experiences degraded performance, partial outages, or major outages, users may assume the issue is related to their local environment, network, API key, or CodexBar itself.

It would be helpful if CodexBar could surface provider-side incidents directly within the application.

Proposed Solution

Introduce provider status monitoring based on official provider status pages.

Examples of supported providers could include:

• OpenAI
• Anthropic
• Google
• xAI
• Any provider that exposes a public status page or status API

When an active incident exists, CodexBar could:

• Display a warning badge or indicator.
• Show the current provider health status.
• Surface a brief incident summary.
• Provide a link to the provider's official status page.
• Optionally send a notification when a new incident is detected.

Possible Status Levels

• Operational
• Degraded Performance
• Partial Outage
• Major Outage

Benefits

• Reduces unnecessary troubleshooting.
• Helps users quickly identify provider-side issues.
• Improves visibility during outages.
• Provides a more reliable operational experience when working across multiple AI providers.

Additional Notes

This could be implemented as an extensible provider health framework so new providers can be added easily without changing the overall UX.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 23, 2026, 12:40 PM ET / 16:40 UTC.

Summary
Current main and the v0.37.2 release already cover the central provider incident-warning request, but this repository's generic onboarding profile calls for conservative keep-open handling instead of auto-closing; any remaining expansion is a maintainer scope decision.

Reproducibility: not applicable. this is a feature request, not a reproducible bug. Source, docs, and tests show the central provider-status behavior already exists on current main.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.
• Include redacted logs or terminal output.

Next step
No autonomous fix PR should run: current main covers the central behavior, and any remaining provider breadth or notification work needs maintainer scope judgment.

Review details

Best possible solution:

Keep the shipped shared provider-status implementation, and let maintainers decide whether to close this as implemented or split narrower follow-ups for component details, link-only providers, or notifications.

Do we have a high-confidence way to reproduce the issue?

Not applicable; this is a feature request, not a reproducible bug. Source, docs, and tests show the central provider-status behavior already exists on current main.

Is this the best way to solve the issue?

Yes for the central request: the current implementation is metadata-driven, polls official Statuspage.io or Google Workspace feeds where available, and reuses shared menu/icon UI. Remaining provider/API breadth and optional notifications are product-scope choices rather than a narrow bug fix.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Status-link-only providers such as Grok/xAI do not currently poll incident APIs, so provider-specific API expansion would need maintainer scope decisions.
• Optional incident notifications are not evident in the current status path and would add notification/product surface beyond the shipped indicator and menu UI.

Codex review notes: model internal, reasoning high; reviewed against 929d55aaf1d7; fix evidence: release v0.37.2, commit f380287041b8.

Label changes

Label changes:

• add P3: This is a low-risk provider-status feature and follow-up-scope request rather than a broken core workflow.
• add impact:other: Provider outage visibility affects operational troubleshooting and user-facing status awareness outside the more specific owned impact classes.
• add issue-rating: 🌊 off-meta tidepool: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:fix-shape-clear: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.

Label justifications:

• P3: This is a low-risk provider-status feature and follow-up-scope request rather than a broken core workflow.
• impact:other: Provider outage visibility affects operational troubleshooting and user-facing status awareness outside the more specific owned impact classes.

Evidence reviewed

What I checked:

• Repository policy read: AGENTS.md was read fully and applied: this review stayed read-only and avoided live provider/keychain probes, using source, docs, tests, and history instead. (AGENTS.md:1, 929d55aaf1d7)
• Vision fit: VISION.md defines CodexBar as a menu bar control surface for provider limits, credits, spend, status, and reset windows, while new features and added maintenance complexity need sign-off. (VISION.md:3, 929d55aaf1d7)
• Status documentation: docs/status.md documents OpenAI, Claude, Cursor, Factory, and Copilot Statuspage.io polling, Gemini/Antigravity Google Workspace incident polling, menu summaries, icon overlays, and status links. (docs/status.md:9, 929d55aaf1d7)
• Status model: ProviderStatusIndicator models operational, partial outage, major outage, critical issue, maintenance, and unknown states; ProviderStatus carries the incident description and updated timestamp. (Sources/CodexBar/UsageStoreSupport.swift:4, 929d55aaf1d7)
• Status polling implementation: UsageStore.refreshProviderStatus checks the status toggle, fetches Statuspage.io or Google Workspace status based on provider metadata, and stores the ProviderStatus per provider. (Sources/CodexBar/UsageStore.swift:877, 929d55aaf1d7)
• Status feed parsing: UsageStore+Status fetches Statuspage.io api/v2/status.json and Google Workspace incidents, maps active incidents to severity indicators, extracts summaries, and preserves updatedAt. (Sources/CodexBar/UsageStore+Status.swift:48, 929d55aaf1d7)

Likely related people:

• Peter Steinberger: Visible blame attributes the shipped status polling, menu status line, README status feature, and provider metadata snapshot to the v0.37.2 tagged commit authored by Peter Steinberger. (role: feature-history owner; confidence: medium; commits: f380287041b8; files: Sources/CodexBar/UsageStore+Status.swift, Sources/CodexBar/MenuDescriptor.swift, README.md)
• ProspectOre: Merged PR Decode provider status feeds off the main actor #1406 improved the provider status feed path by moving status decoding off the main actor and adding regression coverage. (role: recent status-area contributor; confidence: medium; commits: 02c94032c79a; files: Sources/CodexBar/UsageStore+Status.swift, Tests/CodexBarTests/GoogleWorkspaceStatusNetworkTests.swift)
• elijahfriedman: Open PR feat: add live status component submenu for Claude, Codex, and Augment #1714 adds status-component submenus and Augment status-page wiring, overlapping with deeper provider health UI. (role: open related enhancement author; confidence: low; files: Sources/CodexBar/UsageStore+Status.swift, Sources/CodexBar/StatusComponentsMenuView.swift, Tests/CodexBarTests/StatuspageSummaryTests.swift)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.