If your product calls a model API, you no longer own your own uptime. You rent it. Every feature that runs a prompt is only as available as the provider behind it, and most teams have never actually looked at what that number is. They assume it is in the neighborhood of the cloud platforms they grew up trusting, somewhere up around four nines. It is not close.
As of April 2026, Anthropic's API uptime over the prior 90 days was roughly 98.95%, which sounds fine until you do the arithmetic. 98.95% is on the order of eight hours of downtime a month. That is not a rounding error against the 99.99% benchmark most established cloud providers hold; it is two orders of magnitude worse, and it is enough that enterprise customers spent the spring actively shifting workloads to hedge it. OpenAI was not the safer harbor either, logging multi-hour incidents through late 2025 and into early 2026. And the November 2025 Cloudflare outage cascaded straight into ChatGPT and Sora, a reminder that your model provider has providers too, and you inherit all of them.
I am not picking on anyone. Running inference at this scale is genuinely hard, and the honest read is that the whole category is younger and shakier than the marketing suggests. The point is not "switch vendors." The point is that you have a hard dependency with a soft uptime number, and most products are flying blind on it.
Your features are now their incident report
Here is the trap. When the model API has a bad hour, your app does not throw a clean, obvious error that screams "third party down." It does something quieter. A summarize button spins forever. A chat reply half-renders and stops. A background job that enriches records silently falls behind. To your user, your product is broken, and to your dashboard, your servers are perfectly healthy, because they are. The failure is one hop downstream, in a system you can see but not fix.
This is the same lesson as "a 200 OK can still mean down," just moved one layer out. The thing that is failing is not your server returning the wrong code; it is your server faithfully calling a dependency that is slow, throttled, or unreachable, and dutifully reporting itself fine while your feature dies. If you only watch your own front door, you will learn about the provider's outage from your users.
Watch two things, not one
There are two surfaces worth a check, and teams usually monitor neither.
The provider endpoints you depend on. Point a check at the model API's published endpoint and watch three things: is it reachable, what status code does it return, and how slow is it, measured from several regions at once. A model API can be perfectly healthy from one of your machines and unreachable from another because the network path between you happened to break, which is exactly the false signal you do not want waking you at 2am. So decide on consensus, not on a single probe. Multi-region checks that only page when regions agree mean a bad path from one region to the provider gets outvoted instead of escalated.
Your own AI-backed routes. This is the one almost everyone skips. The provider being up does not mean your feature works. Your code wraps the model call in auth, retries, timeouts, queues, and fallbacks, and any of those can be the thing that is broken. Stand up a health route in your own app, something like /health/ai, that does a tiny representative call end to end and returns a real status code based on what actually happened. Then monitor that route the same way. Now you are watching the whole path your user takes, not just the vendor's edge.
Where I have to be straight with you about scope
I would rather lose the sale than oversell what we shipped, so here is the exact boundary. Tallwatch confirms a target is reachable, records its response time per region, and checks the HTTP status code, every minute, from up to six regions, and it opens an incident only when at least two checked regions agree in the same round. If the model endpoint goes unreachable, starts returning an error code, or gets slow, Tallwatch catches it and pages you on consensus.
What Tallwatch does not do yet is read the response body. It cannot open the JSON and see that the call came back with a 200 wrapping an error message, or a rate-limit notice, or a truncated completion. We record how long the response took and what status code it carried; we do not assert on what the bytes say. That is roadmap, and I am not going to pretend otherwise.
The practical consequence: a provider that returns 200 OK with "error": "rate_limited" in the body is invisible to a status-code check, theirs and ours alike. The fix is the health route you control. Make your own endpoint do the real call, inspect the body yourself in your own code where you already can, and return a 503 when the underlying call failed even though the provider sent a 200. Now the failure has a status code, and a status-code check can see it.
A monitoring setup that actually holds
Put together, the setup is small and worth the hour:
- A check on each provider endpoint you depend on, from multiple regions, paging on consensus so one region's bad path to the provider does not page the whole team.
- A check on a health route you own that runs a real, minimal model call end to end and returns a status code reflecting the truth, including the body checks your code can do that an HTTP probe cannot.
- A latency threshold in your head, if not yet in the tool: a model call that used to take two seconds and now takes twelve is degraded, and degraded is a kind of down for anything a human is waiting on.
You can run all of this on the free plan for a small product, three regions and consensus included, and grow into more regions and more alert channels when the dependency starts mattering more than the side project did. The model providers will keep having their eight-hour months. The least you can do is find out before your users do.