How to monitor the AI APIs your product depends on

If you only want to know whether Claude or ChatGPT is down right now, the providers publish that: status.claude.com for Anthropic and status.openai.com for OpenAI. This article is for the other case: your product calls one of these APIs, and you need to know when that call stops working before your customers tell you.

Why the status page is not enough

A provider’s status page reports incidents the provider has confirmed, for the service as a whole. Your feature can fail while it is green:

• Your key or account. A revoked key, an exhausted budget or a billing problem fails only your requests.
• Rate limits. A traffic spike or a lower limit returns 429 responses to you and nobody else.
• Overload. Anthropic answers 529 overloaded_error when the API is temporarily overloaded; a short burst may never become an incident.
• Your model. Models are deprecated and retired on a schedule. A request naming a retired model fails even when everything else is fine.
• The path between you. A proxy, gateway or firewall rule on your side can block the call.

It also works the other way: an incident on the consumer app (claude.ai or ChatGPT) turns the overall status amber while the API your product uses is unaffected. So watch the provider, and watch your own use of it.

Layer 1: the provider’s status, as data

Both status pages serve a machine-readable summary. On 1 November 2026 both answered with an overall indicator of none when everything was operational:

GET https://status.claude.com/api/v2/status.json
GET https://status.openai.com/api/v2/status.json

{"status":{"indicator":"none","description":"All Systems Operational"}, …}

In Uplapse, create a keyword monitor for each URL that requires the text "indicator":"none". When the provider declares an incident, the indicator changes, the keyword is missing and the check fails. Route it to a channel people read but that does not page anyone: it tells you the provider knows, which is useful context, not necessarily your outage.

This summary covers every component on the page, so expect alerts for incidents that do not touch your API.

Layer 2: your key, against an endpoint that runs no model

Both APIs let you read a model’s details without generating anything. Ask for the model you actually use, with your own key:

# Anthropic
GET https://api.anthropic.com/v1/models/<your-model-id>
x-api-key: <a key used only for monitoring>
anthropic-version: <the version your code sends>

# OpenAI
GET https://api.openai.com/v1/models/<your-model-id>
Authorization: Bearer <a key used only for monitoring>

Create an API monitor with the request headers above, expect status 200, and require the model ID in the response. This one check catches a revoked or mistyped key, an account problem, the API being unreachable from outside, and a model your code names that is no longer there.

• Use a separate key for monitoring, with the narrowest permissions the provider offers, so revoking it never takes production down and its traffic is easy to tell apart.
• Uplapse stores request header values encrypted and does not show them again after you save, so the key is not visible to other people in your account.
• These requests count towards rate limits like any other. A check every minute or every five minutes is negligible next to real traffic.

Layer 3: a real request, when you need proof the model answers

Layer 2 proves the API knows your model; it does not prove the model will answer. If generation itself is what fails for you (overload, timeouts on long contexts), add a check that sends the smallest real request: a short prompt with the output limited to a token or two, and an assertion on the response shape, such as the presence of "content" for Anthropic’s Messages API or "choices" for OpenAI’s Chat Completions API.

This one is billed. A request every five minutes is 8,640 requests a month, so keep the prompt tiny, use the model you depend on rather than the largest one, and choose the interval with the cost in mind. Set the timeout from what your product tolerates, not from what the API can take: a model that answers in 40 seconds when your feature gives up at 10 is down for your users.

Layer 4: your own feature

The checks above test the provider from outside. The last layer is your product’s own endpoint that uses the model, a health route that makes one small call, or the background job that summarises documents overnight. Check the endpoint with an API monitor that asserts real output, and give the scheduled job a heartbeat that it pings only after the AI step succeeds. When layer 4 fails and layers 1 to 3 pass, the problem is yours; when they fail together, it is upstream.

Decide what happens before it happens

• Who gets which alert. Provider status to a team channel; your key or your feature failing to whoever is on call.
• The fallback. A second model, a second provider, a queue that retries later, or a message that the feature is unavailable. Monitoring tells you when to switch; it does not switch for you.
• What customers see. If an AI feature is a visible part of your product, it belongs on your status page as its own component, so “summaries are delayed” does not read as “everything is down”.

Start with layers 1 and 2: two keyword monitors and one API monitor per provider take a few minutes to set up and cover most of what goes wrong. See why HTTP 200 is only the first assertion for choosing assertions that hold up.