Show and tell: check cloud and SaaS incidents before Codex changes code

[koko3tallah]

I maintain OutageDeck, and I packaged its live provider-status MCP server with a focused Codex skill for one diagnostic habit: check upstream dependencies before changing code.

The failure mode is familiar: a deploy starts returning 503s or timeouts, Codex begins rewriting the client, and only later does someone notice that AWS, Cloudflare, GitHub, OpenAI, or another dependency has an active incident.

Install the public Git-backed marketplace:

codex plugin marketplace add outagedeck/codex-plugins
codex plugin add outagedeck@outagedeck

Or install just the portable Agent Skill in Codex or another compatible agent:

npx skills add https://github.com/outagedeck/codex-plugins --skill triage-dependency-outages

Start a new session, then try:

• “Before changing code, check AWS, Cloudflare, GitHub, and OpenAI.”
• “Is this 503 from my app or from a provider incident?”
• “Create a citable timeline for the active Cloudflare incident.”
• “Compare GitHub and GitLab uptime over the last 30 days.”

The bundled triage-dependency-outages skill selects the narrowest live tool, correlates vendor update times and affected services with the reported failure, and returns one bounded verdict: vendor incident likely, possible, or not supported. It explicitly continues local diagnosis when the status evidence does not support a provider incident. When installed without the MCP server, it falls back to OutageDeck's anonymous REST API for current status and incident evidence and discloses that MCP-only historical tools are unavailable.

The MCP server exposes 14 tools. Public status, incident, search, and uptime tools are read-only, free, and need no account or API key. Optional account tools preserve the host's confirmation rules, and the skill treats custom-provider deletion as destructive.

Important evidence boundary: OutageDeck reads each vendor's official status feed about every 10 minutes. It does not use social reports or synthetic probes, so it is never earlier than the vendor and it cannot rule out a regional, account-specific, or newly emerging issue. A degraded status is corroborating evidence, not proof that a particular stack trace has that cause.

• Plugin marketplace and source (MIT): https://github.com/outagedeck/codex-plugins
• Portable skill and security audit: https://www.skills.sh/outagedeck/codex-plugins/triage-dependency-outages
• MCP documentation: https://outagedeck.com/developers/mcp?utm_source=github&utm_medium=discussion&utm_campaign=codex_plugin
• Live service: https://outagedeck.com/?utm_source=github&utm_medium=discussion&utm_campaign=codex_plugin
• Versioned release: https://github.com/outagedeck/codex-plugins/releases/tag/v0.1.1

The package passes the current OpenAI skill and plugin validators, installs through the Codex CLI, and has a public CI check against the live 14-tool MCP contract.

I would value feedback on the verdict boundary: what evidence would make you trust Codex to stop code changes and recommend waiting or mitigation during a vendor incident?