Monitor the OpenAI API the way your app calls it

What the official status page misses

• Timing. A provider posts an incident after it has confirmed one. Your users can notice first.
• Your account. Quota, billing, and key problems never appear on a public status page.
• Your model. A problem with one model can sit inside a broad “partial outage” banner that is easy to miss.
• Your network path. A request from Frankfurt can fail while one from Ashburn succeeds.

Keep following the official page for context. Use your own check to find out first.

Set up an OpenAI API check

1. In the console, open Checks → API and click Add check.
2. URL https://api.openai.com/v1/chat/completions, or the endpoint your app uses. Under HTTP request, set the method to POST.
3. Under Request headers, add Authorization: Bearer <a dedicated key> and Content-Type: application/json.
4. In HTTP body, send the smallest request that proves the model answers:

   {"model": "<the model you ship>", "max_completion_tokens": 16, "messages": [{"role": "user", "content": "ping"}]}

   Newer OpenAI models reject max_tokens, so use max_completion_tokens. Reasoning models spend tokens before they answer, so leave a little room.
5. Under Assertions, keep Expected status code at 200 and add JSONPath equals on a field you rely on, for example $.object equals chat.completion.
6. Under Advanced, set Request timeout to 15 or 30 seconds, since model calls are slower than a web page. Set Confirmation period to 2 so one slow call does not page anyone. The default is 3.
7. Pick regions. Free checks from 1 region; Pro can use all five: San Francisco, Ashburn, Montreal, Frankfurt, and Singapore.
8. Under Status page, link the check to an “OpenAI” or “AI features” component, and under When the check is down pick Create an incident automatically, or Ask me to review first.

Save, then press Run now once to confirm the request returns 200 before you rely on it.

Prefer to ask your coding agent? Claude Code, Cursor, or Codex can create the same check over the uptime monitoring MCP server.

What it costs

A check every 60 seconds is about 43,000 requests a month per region, or about 216,000 from five regions. Every 5 minutes is about 8,600 per region. Use a separate key with a hard spending limit. If you only need to know the API is reachable, point a frequent check at GET https://api.openai.com/v1/models with your key, which returns the model list without generating tokens.

Reachability or a real request

Check	What it proves	Cost
GET /v1/models with your key	Network, TLS, your key, and the API front door	No tokens
POST /v1/chat/completions with a small token limit	The model you ship answers	A few tokens per run
GET https://status.openai.com/api/v2/status.json	What OpenAI has declared ($.status.indicator is none when all is well)	Free

Run the first two together: the reachability check often, and the real request less often.

What you get

• An alert that means something. One failed run is stored, not sent. When failures in a row reach the confirmation period, one alert goes out by email, or on Pro also by Slack, Discord, PagerDuty, Pushover, or webhook.
• Response time per region. Every run stores its duration and where it ran from, so you can tell whether “OpenAI is slow” is everywhere or one region. There are no latency alerts. A request timeout turns calls slower than your limit into failures.
• A status page that explains it to customers. When the check is confirmed down, the linked component goes down and subscribers hear it from you.
• The same check for every provider. Anthropic, Groq, Deepgram, ElevenLabs, or your own inference endpoint use the same API check. See TTS latency monitoring for voice APIs.

Pricing

• Free: 5 checks, 5-minute interval, 1 region, 14 days of results, 1 status page, email alerts
• Pro, $15/month: 25 checks, 60-second interval, 5 regions, 90 days of results, and Slack, Discord, PagerDuty, Pushover, and webhook alerts

See pricing