Version 20 August 2026
Status and degradation.
What we monitor, what happens when a model or a provider fails, and where our architecture leaves you exposed.
This page does not show live measurements yet
What we monitor: uptime, latency and errors
| Component | What we measure |
|---|---|
| Chat completions API | Availability and error rate per tier |
| Chat | Availability of the web interface |
| Inference (Scaleway, fr-par) | Latency, TTFT and upstream error rate |
| Payments and topping up | Success rate of Checkout and webhooks |
| Dashboard and usage overview | Availability |
If a model fails: the automatic fallback
If the model behind your tier returns an error, a timeout or a 429, we switch automatically to an alternative within the same tier. Your request is retried at most once: a chain of retries costs three generations and six seconds and helps nobody.
If the alternative is weaker or has a smaller context window, we set X-EU-Degraded: true on the response and you pay the lower of the two rates. So we tell you, and you do not pay extra for it.
If the inference provider fails
We have to be clear here, because it is the biggest limitation of version 1: our fallbacks cover a failing model, not a failing provider. All inference runs through one party in the European Union. If they go down, we go down.
That is a deliberate choice. A second provider means a second jurisdiction analysis, a second subprocessor and a second reconciliation, and it would make our promise about where your prompts are processed harder to explain than we can manage. As soon as downtime demonstrably costs money, we will add a second European provider and report it on the subprocessors page.
Until then: do not build a critical process on a single supplier without a fallback. Not on us either.
What we do not promise: no uptime SLA
No throughput SLA and no guaranteed response time. Our inference provider does not give us that guarantee, so we cannot pass it on. What we do: measure, publish what we measure, and say so when a response was produced in a degraded state. Which header carries that signal is documented in the API documentation, and what a degraded response costs you is on the pricing page: the lower of the two rates, never the higher.
Frequently asked questions
Is there an uptime or throughput SLA for the API?
No. Union AI offers no guaranteed availability and no throughput SLA, because our inference provider gives us neither and we will not pass on a promise we cannot keep. What we do instead is measure, publish what we measure, and mark any response that was produced in a degraded state.
What happens if a model fails mid-request?
We switch once to an alternative model within the same tier. If that alternative is weaker or has a smaller context window, the response carries X-EU-Degraded: true and you pay the lower of the two rates. There is at most one retry per request.
How do I know whether my request was degraded?
By the response headers. X-EU-Degraded tells you the answer came from a weaker replacement, X-EU-Routed tells you why the request was rerouted, and X-EU-Model-Tier names the tier it ran on. In the chat, a small label appears next to the answer.
Do failed requests cost credit?
No. If no usable answer came back, nothing comes off your balance. A rerouted request that lands on a weaker model is charged at the lower of the two rates.
What is the biggest single point of failure?
One inference provider. Our fallbacks cover a failing model, not a failing provider, so if that provider goes down, we go down with it. That is a deliberate trade for a simpler jurisdiction story, and it is a reason not to build a critical process on us without a fallback of your own.