API Status Checker

Pings a curated list of common AI and crypto APIs (OpenAI, Anthropic, Google, CoinGecko, Etherscan, etc.) and reports current reachability and response time. Use it to verify that an outage is on their side before debugging your own code.

The checker hits a public health-check or info endpoint on each service — never anything that consumes API credits. Response codes are surfaced verbatim: 200 means up, 5xx means their problem, 4xx with a clear error usually means yours, and a timeout might mean either side or your network in between.

Cross-reference any failure with the vendor's status page (which the tool links to) before reacting. Sometimes the vendor's status page shows green while users see real failures — that's a clue the issue is regional or specific to certain endpoints, not the whole service.

What each check does: send a single GET or HEAD request to a known unauthenticated endpoint (typically /health, /status, /v1/models or similar). Time the round-trip. Report HTTP status code, response time, and any error message in the response body. The endpoints are chosen for non-billable, non-rate-limited public access so the tool doesn't burn your API quota or trigger abuse mitigations on your account. For services without a public health endpoint, the tool falls back to the documentation root or the API root and treats anything 200-399 as 'up.'

Worked example: your app suddenly throws errors when calling OpenAI's chat completion endpoint. Run the checker. OpenAI shows 200 OK, response time 230ms — so the basic API is up from the tool's vantage point. Your app could still be failing because: your specific endpoint (chat completions vs models list) is degraded while the rest of the API is fine; a regional issue affecting your data center; your API key is rate-limited or revoked; your code has a bug that started showing up under new conditions. The checker has narrowed the search space, not solved it. Now go to OpenAI's status page (linked from the tool), scan for incidents, and check your own logs for the actual error message your code is seeing.

Where the tool lies to you: 'green' from a single ping doesn't mean 'fully functional.' Most outages are partial — affecting specific endpoints, regions, or workload types. The health endpoint passing is a necessary but not sufficient signal. Run a synthetic check against your actual code path (your specific endpoint, your specific request shape) for genuine production monitoring; this tool is for ad-hoc 'is it me or them' triage. Also: latency from this tool's vantage point isn't your latency. A 200ms response from the tool's server doesn't mean your users see 200ms — they see whatever their network path produces, which can be wildly different. Don't use the tool's latency numbers as a baseline for SLA discussions; use your own monitoring data.