Platform SLOs & Error Budgets for Internal Platforms (2026)

Q: What is a platform SLO and how is it different from a product SLO?

A platform SLO is a service level objective that an internal developer platform publishes for one of its capabilities, such as ingress routing, deploy pipelines or secrets delivery, measured at the boundary where tenant services or tenant engineers consume it. It differs from a product SLO because its consumers are other engineering teams whose own SLOs depend on it. A platform capability in the tenant request path puts a hard ceiling on every SLO built above it, so the platform SLO is as much a statement about dependency limits as about the platform's own performance.

Q: Why should platform capabilities be split into data plane, control plane and experience plane?

Because reliability composes multiplicatively along a request path and not at all across it. Data-plane capabilities such as ingress, mesh, DNS, secrets at startup and shared brokers fail tenant requests immediately, so they need tight SLOs and a pager. Control-plane capabilities such as the Kubernetes API, GitOps reconcilers and CI/CD only block change and recovery, so they can tolerate looser targets, though they become data-plane problems when autoscaling or self-healing is blocked. Experience-plane capabilities such as portals and dashboards never affect production and should never page anyone.

Q: What availability target can an internal platform realistically commit to in 2026?

A notch below the managed service that backs it. Amazon EKS commits to 99.95% monthly uptime for its standard control plane and 99.99% for provisioned control plane, so a platform ingress built on it should commit to around 99.95% at most and keep headroom for its own failures. Over a 30-day month, 99.95% allows about 21.9 minutes of unavailability, 99.9% allows 43.8 minutes and 99% allows 7.3 hours. Control-plane targets such as 99% deploy success and experience-plane targets such as 99% portal availability are appropriate, not embarrassing.

Q: What SLIs should a platform team measure?

Measure the tenant's experience at the capability boundary rather than component health. For ingress, the share of tenant requests reaching a healthy upstream without platform-attributed errors or added p99 latency. For the control plane, 99th-percentile single-object mutating API latency, which upstream Kubernetes targets at 1s per cluster-day, plus reconcile lag from commit to applied state. For deploys, the share completing within a fixed window from merge without platform-attributed failure. For secrets, the share of pod starts receiving secrets within a bounded time. For the portal, availability and page load.

Q: What should a platform error-budget policy say?

Four things. Scope: which capability, which plane and the boundary where it is measured. Objective and window: the target over a rolling 28 or 30 days with the burn-rate thresholds that page. Attribution: how each incident is assigned to platform, tenant or cloud provider by a named arbiter in the postmortem, with shared faults split. Consequences: when the platform exhausts its budget, risky platform change freezes until it recovers, and when the platform causes a tenant's budget loss, the tenant's budget is credited so they are not frozen for a failure that was not theirs.

Q: Why should the platform credit tenant error budgets for platform-caused outages?

Because without crediting, product teams learn that platform outages cost them their own feature velocity, and they respond rationally by building around the platform or routing around it. Crediting makes the platform's reliability visibly the platform's problem, which is where the incentive belongs, and it keeps the error budget meaningful as a measure of the tenant's own risk. It mirrors per-service cost showback: just as teams should see the cost they cause, they should not pay in budget for reliability loss they did not cause.

Q: Should all tenants of an internal platform get the same SLO?

No. Offer two or three tiers where the higher tier is earned by meeting conditions rather than requested. A tier-1 tenant runs multiple replicas across zones, honours the platform health-check and graceful-shutdown contract, deploys through the paved road and has its own on-call. In return it receives the data-plane SLO, platform pager routing and priority in capacity and incidents. Lower tiers receive best-effort control-plane support. Verify the conditions continuously, because zone spread and replica counts drift after onboarding, and tie tier status to that verification.

Q: How do OpenSLO, Sloth and Backstage fit into platform SLOs?

OpenSLO is a vendor-neutral YAML specification for declaring an SLI, an objective and a time window, which turns the contract into reviewable data rather than a wiki page. Sloth and similar tools generate Prometheus recording rules and multi-window burn-rate alerting rules from SLO declarations, so paging follows the policy automatically. Backstage, or whatever portal you run, should surface each platform capability's current SLO attainment next to the tenant services that depend on it, so teams setting their own targets can see the dependency ceiling. The portal itself remains an experience-plane capability.