Platform Feature

Build SLOs Out of SLOs

Modern applications span dozens of services, teams, and data sources. Composite SLOs unify them into one weighted, holistic reliability score — so you always know how your users actually experience your product.

Get Started Free Book a Demo
Nobl9 · Composite SLO View
Checkout Flow — Component SLOs
Payment API 99.94% Weight 35%
Product Catalog 99.87% Weight 25%
Auth Service 99.91% Weight 20%
CDN / Static Assets 99.72% Weight 10%
Inventory Service 99.98% Weight 10%
Composite SLO
Weighted across 5 services
99.89%
✓ On Track
40+
Supported data sources and monitoring tools
∞
Levels of nesting — SLOs built from other SLOs
1
Unified score representing your entire application
The Concept

What Are Composite SLOs?

A Composite SLO is a service level objective built from the weighted combination of other SLOs — giving you one truthful score that represents the reliability of an entire application, region, or customer journey.

In any modern system, reliability is distributed. Your checkout page depends on your payment API, your CDN, your auth service, your inventory database, and several third-party integrations — each measured separately, each living in a different monitoring tool. No single existing SLO tells you: is checkout actually reliable for my users right now?

Composite SLOs solve this. You define the component SLOs that make up a flow, assign each a weight based on its real user impact, and Nobl9 calculates a single composite error budget and reliability score. The result is a number your product team, your SREs, and your executives can all agree on.

"Not all failures are equal. A payment API outage is not the same as a CDN hiccup. Composite SLOs let you encode that reality — and stop treating every failure as equally important."

This goes beyond simple averaging. Each component SLO is given a weight that reflects how much it actually affects the end-user experience. A 5-minute payment API degradation should burn error budget faster than a 5-minute read-only analytics slowdown. With Composite SLOs, it does.

How it works
Payment API SLO
35%
→
Auth Service SLO
20%
→
Product Catalog SLO
25%
→
CDN SLO
10%
→
Inventory SLO
10%
→
Checkout Composite SLO — 99.89%
Best_Practices_icon_-09

Works across all your tools

Combine SLOs measured by Datadog, Prometheus, New Relic, and 40+ other sources into one composite — no data normalization required.

Error Budget & SLO Budget

Understanding Your Composite Error Budget

Every SLO has an error budget — the amount of unreliability you can afford before you breach your target. With Composite SLOs, error budgets become proportional, weighted, and far more actionable.

What is an SLO Error Budget?

An error budget is the acceptable amount of downtime, errors, or latency violations allowed within a measurement window. If your SLO target is 99.9% availability over 30 days, you have roughly 43.2 minutes of allowable downtime.

Error budgets turn reliability from a vague aspiration into a concrete, negotiable resource. When budget is plentiful, teams can ship fast. When budget runs low, reliability takes priority. This is the heart of the SLO-driven engineering model pioneered by Google's SRE teams and now practiced at companies like ServiceNow, Ford, and Ticketmaster.

How Composite SLOs change error budget math

In a composite, each component SLO contributes to the composite error budget proportionally to its weight. A component with 35% weight that burns 50% of its own budget contributes 17.5 percentage points to composite budget burn — not 50%.

This means you can model scenarios like: "If the payment service degrades to 99.5% for 2 hours, how much composite budget do we burn?" — and get a real answer, not a gut feeling.

Error budgets make the implicit explicit. They transform "the system feels slow" into "we have 8 minutes of latency-budget left this month."

Error budget by SLO target (30-day window)
SLO Target 30-day budget 7-day budget 1-day budget
99% (two nines) 7h 18m 1h 41m 14m 24s
99.5% 3h 39m 50m 24s 7m 12s
99.9% (three nines) 43m 49s 10m 4s 1m 26s
99.95% 21m 54s 5m 2s 43s
99.99% (four nines) 4m 21s 1m 8.6s

Error budget = (1 − SLO target) × window duration

SLO Budget vs. Error Budget

These terms are often used interchangeably. "SLO budget" refers to the same concept — the portion of unreliability your SLO permits. In Nobl9, you track both the raw budget (in minutes or request counts) and the remaining budget as a percentage, making it easy to spot burn trends early.

SLO Burn Rate

SLO Burn Rate: The Early Warning Signal

Burn rate tells you how fast you're spending your error budget relative to the sustainable pace. It's the difference between "we had some errors" and "we're heading for an SLO breach in 4 hours."

What is SLO Burn Rate?

If your SLO window is 30 days and you're consuming your entire error budget in 3 days, your burn rate is 10x. A burn rate of 1x means you're consuming budget at exactly the sustainable pace — you'll use it all up by the end of the window, but no more.

Burn rate was formalized in Google's SRE workbook as the basis for multi-window, multi-burn-rate alerting — the modern standard for SLO-based on-call paging. Instead of alerting on raw error rates (noisy, low precision), you alert when burn rate crosses a meaningful threshold relative to the error budget.

Burn rate in Composite SLOs

Nobl9 calculates composite burn rates automatically. When a component SLO burns fast, you see its weighted contribution to the composite burn rate — making it easy to identify which service is driving reliability risk and prioritize accordingly.

Because composite burn rate is weighted, a high burn rate on a low-weight component won't trigger the same urgency as the same burn rate on a critical component. Your on-call team gets smarter signals.

Burn Rate → Action Table

Burn Rate Budget Left Required Action
>10x Any All-hands page — immediate response
>5x Any Begin immediate investigation
>5x <50% Notify Incident Manager
>2x <10% Page Engineering Lead
>2x Any Schedule investigation
<1x Any Monitor only
Best_Practices_asset_-15

Multi-window burn rate alerting

Nobl9 supports the Google SRE multi-window alerting model out of the box. Set up alerts that fire when burn rate is high over both a short window (1h) and a longer window (6h) simultaneously — dramatically reducing false positives while catching real incidents fast.

How a composite burn event unfolds

T+0

Payment API latency spikes

The Payment API SLO begins burning at 8x. The component error budget drops from 100% to 72% in 30 minutes. Composite burn rate rises to 2.8x (8x × 35% weight).

T+45min

Composite burn rate alert fires

Nobl9 detects composite burn rate >2x over a 1-hour window. Alert sent to on-call engineer via PagerDuty. Composite error budget now at 67%.

T+1h 10min

Root cause identified

SLO Annotation automatically marks the spike. Database connection pool exhaustion traced via Datadog. Fix deployed.

T+1h 40min

Composite SLO stabilizes

Composite burn rate returns to 0.8x. 61% of composite error budget remains for the month. Incident post-mortem opened.

Getting Started

How to Set Up a Composite SLO in Nobl9

Creating a composite is a five-step process. You can do it through the Nobl9 UI, via the API, or declaratively as YAML using SLOs as Code.

Define your component SLOs

Make sure each service or dependency has its own SLO already configured in Nobl9 — connecting to its data source (Datadog, Prometheus, CloudWatch, etc.) and specifying its SLI type (availability, latency, throughput, or custom). If you haven't done this yet, start with Nobl9's SLI Analyzer to recommend targets based on your historical data.

Create the Composite SLO

In the Nobl9 UI, navigate to SLOs → New SLO → Composite. Give it a name that reflects the user journey it represents (e.g. checkout-flow-composite). Select your time window (rolling 30 days is most common).

Add component SLOs and assign weights

Select each component SLO from your library and assign a weight from 0 to 1. Weights should reflect the service's relative impact on the user experience, not its technical complexity. Weights are normalized — you don't need to ensure they sum to 100 manually. A common starting point: weight by transaction volume or by how often this service appears in user-facing critical paths.

Set the composite target and budget policy

Choose your composite reliability target (e.g., 99.9%). This target applies to the weighted combination, not to each component individually. Nobl9 will automatically calculate the composite error budget and start tracking burn rate from the moment the SLO is saved.

Configure composite burn rate alerts

Set up alert policies on the composite SLO using Nobl9's built-in alerting engine. Connect to PagerDuty, Slack, OpsGenie, or any other notification channel. Use multi-window, multi-burn-rate thresholds to get high-precision signals with minimal false positives.

Composite SLO as YAML (SLOs as Code)
apiVersion: n9/v1alpha
kind: SLO
metadata:
  name: checkout-flow-composite
  project: ecommerce
spec:
  service: checkout
  indicator:
    composite:
      components:
        objectives:
          - project: ecommerce
            slo: payment-api-slo
            weight: 0.35
          - project: ecommerce
            slo: auth-service-slo
            weight: 0.20
          - project: ecommerce
            slo: product-catalog-slo
            weight: 0.25
          - project: ecommerce
            slo: cdn-slo
            weight: 0.10
          - project: ecommerce
            slo: inventory-slo
            weight: 0.10
  objectives:
    - target: 0.999
      displayName: "Checkout 99.9%"
  timeWindows:
    - unit: Day
      count: 30
      isRolling: true

Works with GitOps workflows

Composite SLOs defined as YAML can be stored in version control, reviewed in pull requests, and deployed via CI/CD — the same workflow your team already uses for infrastructure and application config.

Read SLOs as Code docs →
Use Cases

Who Uses Composite SLOs and Why

Composite SLOs are useful anywhere a user experience depends on multiple independently-measured services.

E-commerce

Full checkout flow reliability

Combine payment, inventory, auth, and CDN SLOs into one "checkout experience" composite. When the VP of Engineering asks "was checkout reliable last week?" — one number answers the question.

Platform / Infra

Multi-region availability

Weight regional deployments by traffic share. A US-East SLO at 60% weight, EU-West at 30%, and APAC at 10% gives a globally-accurate reliability picture weighted by actual user exposure.

SaaS Products

Product-level SLOs for customers

Expose a single "product SLO" to customers in your status page or SLA documentation — backed by a Nobl9 composite that aggregates across all underlying services.

Enterprise

Shared service accountability

Platform teams own shared services (auth, messaging, storage). With composite SLOs, product teams can clearly see how shared service reliability contributes to their own composite scores — and hold platform teams accountable.

Microservices

Service mesh observability

In complex service meshes, no single SLO tells the whole story. Build composites that map to bounded contexts or domains — aligned with your team topology rather than your infrastructure topology.

Executive Reporting

Board-level reliability dashboards

Composite SLOs collapse technical complexity into executive-readable metrics. Display "Reliability Health" as one green/yellow/red indicator on a Service Health Dashboard without losing the ability to drill into components.

Comparison

Composite SLOs vs. Alternative Approaches

Teams often try to solve multi-service reliability visibility before discovering Composite SLOs. Here's how the approaches compare.

Approach Cross-tool metrics User-impact weighting Error budget tracking Burn rate alerting Nesting / hierarchy
Nobl9 Composite SLOs ✓ ✓ ✓ ✓ ✓
Single-tool SLOs (Datadog) ✗ ✗ ✓ Limited ✗
Manual dashboards (Grafana) ✓ Manual only Manual only ✗ Manual only
Averaging SLOs in spreadsheet Manual Manual Manual ✗ ✗
Prometheus recording rules Prometheus only Custom code Custom code Custom code Custom code
FAQ

Common Questions About Composite SLOs

Everything you need to know before implementing Composite SLOs in your reliability program.

Full documentation →
Can I nest Composite SLOs inside other Composite SLOs?

Yes. Nobl9 supports multi-level nesting, so you can build regional composites and then roll those into a global composite. This mirrors how complex organizations structure their reliability programs — from service-level to team-level to business-unit-level.

What happens when a component SLO has missing data?

Nobl9 handles data gaps gracefully. If a component SLO has a data gap, the composite recalculates based on available components. You can configure whether gaps should be treated as "good" or "bad" events — depending on your reliability philosophy and monitoring maturity.

How do I choose weights for each component?

Start with business impact: how much does this service's failure affect the core user journey? Common signals include transaction volume, user-facing request share, and historical incident severity. You can always adjust weights after observing composite behavior in production. Nobl9's SLI Analyzer can help surface historical patterns to inform your weighting decisions.

Do I need all component SLOs in the same Nobl9 project?

No. Component SLOs can come from any project within your Nobl9 organization. This makes cross-team composites straightforward — a platform team's SLO and a product team's SLO can coexist in the same composite even if they're maintained by different groups.

Can I alert on composite burn rate the same way as a regular SLO?

Yes. All Nobl9 alerting features — including multi-window burn rate alerting, budget exhaustion alerts, and notification routing to PagerDuty, Slack, OpsGenie, or ServiceNow — work identically on Composite SLOs as on regular SLOs.

How does backtesting work with Composite SLOs?

Nobl9's SLO Backtesting feature works with composites. You can ingest historical data from all component sources and see what your composite error budget burn rate would have been over the past 30, 60, or 90 days — before you commit to a target. This eliminates the wait-and-see period that plagues most SLO programs.

Related Topics

Explore More on SLO Reliability

SLO Backtesting Error Budget Alerting Service Health Dashboard SLO Annotations SLO Oversight Guide to Error Budgets Guide to SLOs New to SLOs? Composite SLO Docs All Integrations

Ready to see your full application reliability?

Start with a free trial or book a 30-minute demo with our reliability engineering team.

Get Started Free Book a Demo