Your agent can check whether the cloud is down before it debugs your code

Connect

MCP is an open protocol, and this is a plain Streamable HTTP server at https://outagedeck.com/api/mcp. It works the same in every client that speaks it. There is no vendor build, no SDK to install, and no key required, so most setups are one line or one paste.

claude mcp add --transport http outagedeck https://outagedeck.com/api/mcp

{
  "mcpServers": {
    "outagedeck": {
      "url": "https://outagedeck.com/api/mcp"
    }
  }
}

curl -X POST https://outagedeck.com/api/mcp \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/call",
    "params": {
      "name": "get_provider_status",
      "arguments": { "provider": "aws" }
    }
  }'

The tools

10 read-only tools cover the questions agents actually ask. Provider arguments accept slugs, vendor names, or product names: "claude" resolves to Anthropic, "gcp" to Google Cloud.

• get_provider_status

  Live status for one tracked provider: overall state, non-operational services, and open incidents, read from the vendor's official status feed. Accepts a slug, provider name, or product name (e.g., "claude" resolves to Anthropic). Use this first for any "is X down?" question.

• check_my_stack

  One verdict across up to 12 providers: whether any vendor in the list is reported as having a problem right now. Use before debugging an integration failure to answer "is it us or them?" in a single call. Returns a shareable status-board link and a prefilled alert setup link.

• list_active_incidents

  Every incident currently open across all tracked providers, most severe first. Optionally filter by severity (critical, major, minor, maintenance). Use to answer "what is down right now?" across the whole cloud landscape.

• get_incident_details

  Full detail for one incident: updates from the official incident source in chronological order, the services OutageDeck matched to it, severity, and resolution state. Pass the incident slug returned by list_active_incidents or get_provider_status. Use to read what the official source has actually said about an outage.

• get_uptime

  Independent uptime record for one provider over a trailing window (7-90 days, default 30), computed from OutageDeck's own observations of the vendor's official feed: share of time free of major outages, strict uptime with partial outages counted as downtime, and total impaired durations.

• get_outage_report

  A reliability summary across every tracked provider over a trailing window (7-90 days, default 30): incident totals, severity and category breakdowns, the providers hit hardest by major outages, and the longest-running severe incidents. Use to answer "which vendors had outages recently?" or to compare vendor reliability.

• search_providers

  Find tracked providers by name, product name, or fragment ("postgres", "auth", "claude"). Returns slugs to use with the other tools plus each match's current status. Use when a provider argument did not resolve or to discover what OutageDeck tracks.

• watch_provider

  Starts sending the caller outage alerts for one provider, either from the tracked catalog or from their own custom providers. Requires an API key. Alerts are emailed to the account address; the other channels (Slack, Teams, Discord, webhook) are set up on the account page, so no webhook URL ever has to be shared in a conversation.

• search

  Search everything OutageDeck tracks: cloud and SaaS providers, and their incident history. Returns citable results with stable ids for the fetch tool. Use for open questions like "who had outages last week" or "find the GitHub Actions incident"; use get_provider_status when the question is simply whether one named vendor is down right now.

• fetch

  Retrieve the full text of one search result by its id: a provider's current status with its services and open incidents, or an incident's complete timeline. Ids come from the search tool.

Managing your own custom providers

4 more tools let an agent manage the vendors OutageDeck does not track for everyone. These identify the account they act on, and every call is scoped to that account's own providers and its plan's quota. Feeds behind authentication are set up on the account page instead, so credentials never travel through a conversation.

There are two ways to identify yourself, and your client picks the one it supports. Editors and terminals take an API key as a header. Hosts that add a connector from a settings screen usually offer only OAuth, so this server is a full OAuth 2.1 authorization server too: choose OAuth, sign in, and approve the connection on a screen that names the application and where it will send the result. Approving creates an API key on your account, which means the connection is listed on your account page and revoking it there disconnects the client. Nothing to configure either way: registration and discovery happen automatically.

• list_custom_providers

  Lists the custom providers on the caller's own OutageDeck account: vendors they registered themselves by pointing at a status feed we do not track in the public catalog. Requires an API key, and only ever returns that key owner's providers.

• add_custom_provider

  Registers a vendor OutageDeck does not track by pointing at its Statuspage or Instatus status page, so it joins the caller's account with live status, incident history, and alerting. Requires an API key and a plan that includes custom providers. The feed is read live before anything is saved, and it must be reachable from the public internet. Feeds behind authentication are set up on the account page instead, so credentials never travel through a conversation.

• update_custom_provider

  Renames one of the caller's custom providers, points it at a different status page, or pauses and resumes its checks. Requires an API key. A new address is read live before it is stored.

• remove_custom_provider

  Deletes one of the caller's custom providers and its stored incident history, freeing a slot on their plan. Requires an API key.

Connecting also installs a prompt your client can surface as a command. Claude Code shows it as /mcp__outagedeck__triage_outage:

• triage_outage

  Work out whether a failure is your own change or a vendor outage: check every vendor the stack depends on, dig into anything not operational, and report a verdict with citations.

• cover_my_stack

  Work out which vendors this project actually depends on, then set up outage alerts for them, registering any vendor OutageDeck does not track yet from its own status page. Needs an API key on the connection.

What to ask once connected

No special phrasing is needed. The agent picks the right tool from a plain question and cites the page a human can open.

• “Is Cloudflare down right now?”

  → get_provider_status

• “Check my stack: AWS, GitHub, Vercel, OpenAI. Is it us or them?”

  → check_my_stack

• “What cloud outages are happening right now?”

  → list_active_incidents

• “What has the vendor said about this incident so far?”

  → get_incident_details

• “How reliable was Supabase over the last 90 days?”

  → get_uptime

• “Which vendors had the worst outages this month?”

  → get_outage_report

Limits and keys

Keyless calls share the public API's anonymous hourly limit per IP, which is plenty for an agent that checks status when something fails. Connecting, listing tools, and pings never count against it; only tool calls do, one unit each, so batching several into a single request costs the same as sending them one at a time. If your agents check status constantly, an API key raises the limit and every paid plan includes one:

claude mcp add --transport http outagedeck https://outagedeck.com/api/mcp \
  --header "Authorization: Bearer YOUR_API_KEY"

The same key works on the REST API. Keys are created on your account page; the free tier includes email outage alerts for 5 providers, no card required. A connector that authorized over OAuth gets its own key automatically, listed there like any other.

What the answers are made of

• Every status comes from the provider's own official status feed, ingested about every 10 minutes. OutageDeck reports what vendors publish; it does not probe or crowd-source.
• Uptime numbers are OutageDeck's independent record of those feeds, with major and partial outages reported separately so a regional event never reads as a platform-wide one.
• The server is read-only and stateless: no sessions, no conversation data received, nothing stored about the caller beyond standard rate accounting.
• Tool responses include OutageDeck links so your agent can cite a page a human can open. The same pages, API, and outage alerts cover everything the tools return.

Common questions