An SLA percentage on a pricing page tells you almost nothing until you know what it actually excludes.
The real question for an operator routing production traffic through Kyma API isn’t “what’s the uptime number” — it’s “what happens to my workflows during the minutes it’s not met.”
Quick Answer: Kyma API’s SLA covers gateway-layer availability — whether Kyma itself is reachable and routing correctly. It does not cover, and cannot cover, outages on the underlying model providers (Anthropic, OpenAI, Google) it routes to. A gateway outage and a provider outage look identical to your workflow unless you’ve built in visibility to tell them apart.
What an API gateway SLA actually promises
A gateway sits between your workflow and the model providers it routes to. Its SLA is scoped to what it controls: the routing layer itself.
That means the SLA covers:
- Whether requests reach Kyma’s endpoint and get routed
- Whether Kyma’s own infrastructure (not the model providers behind it) is up
- Response time for the routing decision itself, separate from the model provider’s response time
It does not cover:
- A model provider being down or degraded — that’s the provider’s own SLA, not Kyma’s
- Rate limiting imposed by the provider, not by Kyma
- Your own configuration errors (bad routing rules, expired provider keys)
This distinction matters because from inside your workflow, a Kyma outage and an Anthropic outage produce the same symptom: failed requests. Without separate monitoring, you can’t tell which one happened.
Reading the fine print that matters
Three details in any gateway SLA are worth checking before you depend on it for production traffic:
Measurement window. A “99.9% uptime” claim measured monthly allows roughly 43 minutes of downtime per month. The same number measured annually allows the same total minutes, but they could all land in one bad week instead of being distributed. Ask which window applies.
What counts as “down.” Some SLAs only count a full outage as downtime — degraded performance (2x normal latency, partial routing failures) doesn’t count against the percentage even though it breaks your workflow in practice.
Credit vs. remedy. Most gateway SLAs offer service credits for missed targets, not compensation for the downstream cost of your failed workflow. A missed publish deadline or a broken automation run isn’t covered by a billing credit.
Building a workflow that survives a gateway outage
Because the SLA only covers the gateway layer, the practical reliability work is yours to build:
1. Separate your monitoring from your provider’s monitoring
Don’t rely solely on Kyma’s status page. Add your own health check that sends a lightweight test request through the gateway on a schedule, so you detect degradation before a full batch job fails.
2. Log which layer failed
When a request fails, capture enough detail to distinguish “Kyma returned an error” from “the underlying provider returned an error through Kyma.” This is a small logging addition that pays off the first time you need to open a support ticket and can point to exactly where the failure occurred.
3. Keep a documented fallback path
For workflows where an outage has real cost (a scheduled publish, a customer-facing feature), document — even if you don’t automate — a manual fallback: routing a request directly to a provider, bypassing the gateway, for the duration of an incident.
4. Don’t treat “managed” as “unbreakable”
A managed gateway removes the work of building routing and key management yourself. It doesn’t remove the need to plan for its failure. Treat Kyma’s SLA the same way you’d treat any vendor dependency: useful, but not a substitute for your own contingency plan.
When the SLA matters more or less
Matters more: unattended overnight automation, customer-facing features with no human in the loop to catch a failure, workflows with a hard publish deadline.
Matters less: personal content pipelines with a human reviewing output before it ships, low-frequency batch jobs where a delayed retry the next day has no real cost.
If your use case falls in the second category, the SLA number is closer to a nice-to-know than a deployment blocker.
Frequently Asked Questions
Does Kyma API’s SLA cover the model providers behind it?
No. The SLA is scoped to the gateway layer Kyma operates. Model provider outages are covered by that provider’s own terms, not Kyma’s.
How do I tell a Kyma outage apart from a provider outage?
You need your own logging that captures the response source, not just pass/fail. Without it, both failures look identical from your workflow’s perspective.
Is a single-gateway setup a single point of failure?
Yes, functionally. Routing all providers through one gateway consolidates management at the cost of introducing a shared failure point. This is a deliberate trade-off, not an oversight — see the Kyma API in a managed agent stack breakdown for when that trade-off is worth making.
Should I run a fallback gateway alongside Kyma?
Only if your workflow’s cost of downtime justifies the added complexity. For most lean operator stacks, a documented manual fallback (direct provider access for critical workflows) is enough without maintaining a second live gateway.
Does this apply the same way to OpenRouter?
The same gateway-vs-provider distinction applies to any aggregation layer, including OpenRouter. See OpenRouter rate limits explained for how a similar layer handles throttling and reliability trade-offs.
Explore the Kyma API Tool Overview
The Kyma API tool page covers current pricing tiers, access options, and where Kyma fits versus a direct provider or OpenRouter setup.
It covers:
- Current SLA terms and what they cover in practice
- How Kyma compares to OpenRouter and direct provider access
- Setup guidance for common automation platforms