Treat health as a signal.

A provider can become slow, constrained or unavailable while the application still needs a deliberate outcome. Explore the reliability concepts around an inference request.

Distinguish the failure modes.

Elevated latency
The response may complete, but too late for a task’s budget. A production system needs a defined measurement window and a policy for acting on it.
Rate limit or capacity rejection
A 429 example is not the same as a model-quality problem. Retry timing, fallback limits and duplicate-request behavior need explicit handling.
Fallback
An alternate route changes the execution context. A useful record should retain the attempted path and the reason for the change.
Timeout or incomplete response
A failure should remain visible in the trace instead of being silently removed from an aggregate.

No live status claim.

Healthy, degraded and fallback labels in the homepage panels are simulated. This website does not poll provider health or publish a measured control-plane uptime figure.

The browser diagnostics page checks this frontend’s available browser features and static assets. It is not a provider service-status page.

Bring the question.
Keep the context.

Talk to engineering ↗Read the documentation →