What is Model Uptime?

Why It Matters

Any feature built on top of an AI model is only as reliable as the model's own uptime, so a drop in model uptime shows up directly as a broken or degraded user experience. It's tracked separately from general system uptime because a model API can report as online while still timing out or returning errors on individual requests, a failure mode plain server uptime checks can miss entirely. Since model uptime often depends on a third-party provider, it's largely outside a product team's direct control, which is why teams that ignore it get caught without a fallback when an outage hits. Watching this number closely is what tells a team when it's time to add a secondary model or a graceful degraded state rather than letting the feature fail outright. It also gives a concrete, provider-attributable number to point to when diagnosing whether a problem is the product's own bug or an upstream outage.

Example

An AI-powered feature depends on a third-party model API that is unavailable for 45 minutes during a month with 720 total hours. Model uptime is 720 hours minus 0.75 hours, divided by 720, times 100, which equals about 99.9%. Products built on top of external AI model providers typically need a fallback plan, like a secondary model or a graceful error state, for the windows when model uptime dips, since that downtime is outside the product team's direct control.

Frequently Asked Questions

• What counts as downtime for model uptime?

  Downtime includes any period where the model API fails to respond, times out, or returns errors instead of successful completions, not just full outages where the service is completely unreachable. A model that's technically online but consistently erroring on requests still counts as down for this metric.

• How is model uptime different from inference latency?

  Model uptime measures whether requests succeed at all, while inference latency measures how long a successful request takes to return a response. A model can have excellent uptime but still frustrate users with slow latency, so the two are tracked as separate metrics.

• What's a good model uptime target?

  Many teams building on third-party model providers look for something in the 99.9% range or higher, similar to standard cloud infrastructure uptime targets. Even at 99.9%, that still allows for roughly 45 minutes of downtime a month, which is enough to justify a fallback plan.

• Who is responsible for model uptime?

  When a team relies on a third-party model API, uptime is largely controlled by that provider rather than the product team itself. That's different from internally hosted models, where the team building the feature also owns the infrastructure keeping the model available.

• How can a team protect a product from model uptime issues?

  The standard approach is building a fallback, such as routing to a secondary model provider or showing a graceful error state, for the windows when the primary model is down. Monitoring model uptime continuously is what alerts a team to switch over to that fallback quickly rather than discovering the outage through user complaints.