How AI agents check whether AWS or OpenAI is down
An AI agent checks provider status by calling an incident wire that reads the official status feeds for AWS, Google Cloud, Azure DevOps, GitHub, Cloudflare, OpenAI and Anthropic. It filters by provider and time window and reads posted incidents with timestamps, rather than inferring an outage from one failed request.
/mcp. Nothing here needs an API key or a signup.
An agent that retries a 503 forever is a familiar and expensive bug. The agent has one data point, its own failed call, and no way to tell a provider incident from a bad region, a rate limit, or its own broken credentials. Those four situations have four different correct responses.
The seven providers on the wire
| Provider | Filter value | Feed it reads |
|---|---|---|
| AWS | aws | AWS Service Health |
| Google Cloud | gcp | Google Cloud status |
| Azure DevOps | azure | Azure DevOps status |
| GitHub | github | GitHub Status history |
| Cloudflare | cloudflare | Cloudflare Status history |
| OpenAI | openai | OpenAI status history |
| Anthropic | anthropic | Anthropic status history |
That is seven feeds, not the whole internet. If your dependency is not on this list, the wire will return nothing for it, and an empty result means "nothing found here," never "everything is fine everywhere."
The call an agent makes
# free preview, top 3 results, no payment and no wallet curl "https://thebotwire.com/status/preview?provider=aws&since=24h" # paid, $0.005: incidents across all seven providers in the last 3 days curl "https://thebotwire.com/status/latest?since=3d&limit=20" # one provider, one keyword curl "https://thebotwire.com/status/latest?provider=openai&q=api&since=24h"
Parameters are provider (the seven values above), q (keyword), since (30m, 2h, 24h, 3d, 14d) and limit (1 to 50). Incidents are sparse, so this wire keeps a 7-day history window and defaults to a 3-day lookback rather than 24 hours. The route costs $0.005 per call in USDC on Base, with no API key.
The retry decision this is actually for
The value is not a status page an agent can read. It is a branch an agent can take.
- Confirmed provider incident. Stop retrying, back off long, and tell the user
what is down and when it was posted. Retrying into a regional outage burns budget and changes nothing.
- No incident posted, your call still failing. Look at your side first:
credentials, quota, region, payload. Most of the time this is the branch, and it is the one agents skip.
- Incident posted and resolved. Retry now rather than backing off, because the
window closed.
- Degraded, not down. Reduce concurrency instead of stopping. Partial capacity
rewards patience and punishes parallelism.
One call at the top of an error handler, at half a cent, replaces a retry storm. That is the whole economic argument.
Status feeds lag, and an agent should know it
Provider status pages are posted by humans after an incident is confirmed internally, so there is a real gap between "things are broken" and "things are posted as broken." An agent that treats a quiet feed as proof of health will draw the wrong conclusion during the first fifteen minutes of an incident, which is exactly when it matters.
Two habits handle this honestly. Report the posting timestamp alongside the finding so a human can judge the lag. And treat an empty result as absence of a posted incident, not as a health check. That distinction is the same one that keeps agents from inventing answers generally, covered in why agents hallucinate recent events.
For broader situational awareness during a large outage, the tech and Hacker News wires often carry reports before a status page updates. Which endpoint owns which question is listed in the routing table, and the security-side equivalent of this pattern is in how agents monitor CVEs and advisories.
FAQ
Can an AI agent tell whether AWS is down right now?
It can read what AWS has posted right now, which is a different thing from knowing whether AWS is degraded. If an incident is posted, the agent has a confirmed answer with a timestamp. If nothing is posted, the honest report is that no incident has been published, and the agent should then check its own side.
Why not just poll the status pages directly?
You can, and for one provider that is reasonable. Seven providers means seven feed formats, seven parsers and seven things that break quietly when a provider changes its feed. One wire with one response shape and a per-item source link removes that maintenance surface.
How far back does the incident history go?
This wire keeps a 7-day window, because incidents are sparse enough that a 72-hour window would return empty most days. Live freshness figures, including the last poll time and the observed interval of about 299 seconds between ingest runs, are published at /health.
Does the agent need an account to call this?
No. The route answers HTTP 402 with a price offer, an x402 client signs a USDC authorization on Base and retries, and the data comes back. Setting up the wallet takes three things and no signup, listed in what an agent wallet needs on Base.
Sources
Provider incident data on this wire comes from the official status feeds, including the AWS Health Dashboard, whose posted service events and post-event summaries are the authoritative record for AWS availability. Poll cadence and wire count for this service are live at thebotwire.com/health.
Related: How do AI agents monitor CVEs and security advisories? · Why do AI agents hallucinate recent events, and how do you fix it?