Nobl9

Nobl9 is a commercial, SaaS SLO-management platform: you define a service level objective once — a target percentage, a compliance window, and a query against whichever metrics backend actually holds the data — and Nobl9 computes attainment, tracks the error budget, evaluates multi-window burn-rate alert policies, and reports on all of it centrally, regardless of whether the underlying metric lives in Prometheus, Datadog, CloudWatch, or one of several dozen other places. The problem it exists to solve is organizational as much as mathematical: without a central layer like this, error-budget tracking tends to live as a per-team spreadsheet or a hand-rolled dashboard, each one computing burn rate slightly differently, each one trusted only by the team that built it. Nobl9's pitch is that an SLO is a cross-team contract — and a contract enforced by forty different spreadsheets, each with its own idea of how the math works, isn't really being enforced at all.

What Nobl9 is and the problem it solves

☺ Like you're 10: It's a company's product that watches your team's error-budget math for you, no matter which monitoring tool actually holds the numbers, so nobody has to trust a spreadsheet only one engineer understands.

Nobl9 was founded in 2019 as a commercial SLO-management platform and has since positioned itself as one of the more visible vendors behind the industry's push to treat SLOs as a first-class, cross-team artifact rather than a private team convention — it was also among the organizations behind the creation of OpenSLO, an open, vendor-neutral specification for describing service level objectives in YAML, alongside Google and other contributors. Treat that lineage as real but not identical to Nobl9's own product: Nobl9's manifests use their own apiVersion: n9/v1alpha shape rather than being literally interchangeable with an arbitrary OpenSLO file, and exactly how much the two formats converge has shifted as both have evolved — verify current interoperability claims on Nobl9's own documentation rather than assuming one is simply the other.

This course's SLIs, SLOs & error budgets page and multi-window, multi-burn-rate alerting both work through the arithmetic behind a single service's error budget by hand — the numerator-over-denominator query, the burn-rate formula, the four-tier alert table. That arithmetic doesn't get harder as an organization grows past one service; it gets harder because it has to be repeated, correctly, dozens or hundreds of times, by different teams, against different backends, with the result trusted by people who never touched the underlying query. Nobl9 exists to be the one place that arithmetic happens: define the SLO once as a manifest, point it at whatever backend actually has the data, and the platform computes attainment, evaluates the burn-rate alert policy, and produces the error-budget report the same way, every time — regardless of which of an organization's several observability tools originally emitted the metric.

Architecture: Projects, Services, SLOs, and how metrics get in

☺ Like you're 10: Nobl9's own computers do the watching and the math; your metrics either get pulled in directly over the internet, or — if they're locked away inside your own network — a small program you run yourself carries them out.

Nobl9's data model is a strict hierarchy, and every object below sits inside the one above it. A Project is the top-level namespace and RBAC boundary — usually one per team. A Service is a logical grouping inside a Project — "checkout-api," "payments-gateway" — that one or more SLOs attach to. An SLO holds one or more Objectives, each an actual numeric target (99.9%) plus the query pair that measures it. An AlertPolicy attaches to an SLO and encodes burn-rate conditions across paired windows, exactly like the tiers in multi-window, multi-burn-rate alerting. An AlertMethod is where a firing policy actually goes — Slack, PagerDuty, Opsgenie, a generic webhook, email, or Microsoft Teams.

Every Objective's query has to reach an actual metrics backend, and Nobl9 offers two structurally different ways to make that connection — picking the right one for a given backend matters more than it looks, and getting it backwards is the single most common "why is this SLO stuck with no data" support story:

• Direct. For backends reachable over the public internet with an API key or service-account credential — Datadog, Amazon CloudWatch, Google Cloud Monitoring, BigQuery, Splunk Observability, and most other SaaS or cloud-native sources — Nobl9's own SaaS backend calls that backend's API directly, on a schedule, using credentials stored inside Nobl9 itself.
• Agent. For backends that live inside a private network — an internal-only Prometheus or Thanos endpoint behind a VPN, a self-hosted Elasticsearch cluster with no public ingress — a small Nobl9-provided agent runs inside that network, most commonly as a container. It makes an outbound-only connection to Nobl9's control plane, pulls metrics locally, and forwards results out; nothing inbound has to be opened on your firewall for Nobl9 to reach in. It's the same outbound-only shape Gremlin's own agent uses for a different reason — letting a vendor's SaaS control plane act on infrastructure it's never allowed to directly connect into.

Once a connection exists, the loop is continuous: on a schedule, Nobl9 runs each Objective's good/total query pair against its configured Data Source, stores the result, and recomputes current attainment and remaining error budget over the SLO's compliance window — rolling or calendar-aligned, the distinction covered in full in SLO windows & composite SLOs. Every attached AlertPolicy re-evaluates its burn-rate conditions against that same continuously updated budget and fires through its AlertMethod the moment a condition trips.

Two features build on that loop worth knowing by name. A composite SLO doesn't query a backend directly at all — its indicator is a weighted combination of other SLOs' own results, letting a "checkout journey" SLO roll up the attainment of every service the checkout flow actually depends on into one number, without redefining any of the underlying queries; see SLO windows & composite SLOs for the composite-SLO math itself. Replay backfills an SLO's error-budget history against data that already exists in the backend at the moment the manifest is applied, rather than starting the budget artificially full at 100% from a blank slate — useful for retroactively grading how a service actually performed before anyone got around to writing its SLO down.

The manifests you actually write

☺ Like you're 10: A handful of YAML files: one names your project, one names a service, one states the numeric target and where the numbers come from, and one says who gets paged and how fast.

Nobl9 objects are plain YAML, applied the same way kubectl apply applies a Kubernetes manifest. This example continues the checkout API's 99.9%, 30-day rolling SLO already worked through by hand in SLIs, SLOs & error budgets and multi-window, multi-burn-rate alerting — the same PromQL, now expressed as a manifest instead of hand-written Prometheus recording rules.

# project.yaml
apiVersion: n9/v1alpha
kind: Project
metadata:
  name: checkout-team
  displayName: Checkout Team
---
# service.yaml
apiVersion: n9/v1alpha
kind: Service
metadata:
  name: checkout-api
  project: checkout-team
spec:
  description: The checkout API
---
# checkout-slo.yaml — same 99.9% target, same 30-day rolling window, same PromQL
# as the hand-written recording rules in multi-window-burn-rate-alerting
apiVersion: n9/v1alpha
kind: SLO
metadata:
  name: checkout-availability
  project: checkout-team
spec:
  description: 99.9% of checkout requests succeed, 30-day rolling window
  service: checkout-api
  indicator:
    metricSource:
      name: prod-prometheus   # references an already-configured Data Source (Direct or Agent)
      kind: Agent
  objectives:
    - displayName: ok
      target: 0.999
      countMetrics:
        incremental: true
        good:
          prometheus:
            promql: sum(rate(http_requests_total{route="/checkout",code!~"5.."}[5m]))
        total:
          prometheus:
            promql: sum(rate(http_requests_total{route="/checkout"}[5m]))
  timeWindows:
    - unit: Day
      count: 30
      isRolling: true
  alertPolicies:
    - checkout-burn-rate-fast
---
# alert-policy.yaml — the SRE Workbook's fast "page" tier: 14.4x over 1h, confirmed by 5m
apiVersion: n9/v1alpha
kind: AlertPolicy
metadata:
  name: checkout-burn-rate-fast
  project: checkout-team
spec:
  description: Page — burning the 30-day budget fast enough to exhaust it in ~2 days
  severity: Critical
  conditions:
    - measurement: burnedBudget
      value: 0.02          # 2% of the 30-day budget
      lookbackWindow: 1h
      op: gt
    - measurement: burnedBudget
      value: 0.02
      lookbackWindow: 5m
      op: gt
  alertMethods:
    - name: checkout-pagerduty
      project: checkout-team
---
# alert-method.yaml
apiVersion: n9/v1alpha
kind: AlertMethod
metadata:
  name: checkout-pagerduty
  project: checkout-team
spec:
  pagerDuty:
    integrationKey: ${PAGERDUTY_INTEGRATION_KEY}

Day-to-day commands

☺ Like you're 10: A handful of commands cover almost everything: log in, apply the files, ask what's currently defined, and backfill history for something you just wrote.

# authenticate the CLI against an org (client ID/secret from Nobl9's own settings)
$ sloctl config add-context prod --client-id "$N9_CLIENT_ID" --client-secret "$N9_CLIENT_SECRET"
$ sloctl config current-context

# apply everything for a service in one pass — order inside the file list doesn't matter,
# sloctl resolves references (project, service, alertMethods) across the whole apply
$ sloctl apply -f project.yaml -f service.yaml -f checkout-slo.yaml \
    -f alert-policy.yaml -f alert-method.yaml

# inspect what's live
$ sloctl get project
$ sloctl get service -p checkout-team
$ sloctl get slo -p checkout-team
$ sloctl get slo checkout-availability -p checkout-team -o yaml   # manifest + live status
$ sloctl get alertpolicy -p checkout-team
$ sloctl get datasource                                            # configured Direct/Agent sources

# backfill error-budget history against data that already exists in the backend
$ sloctl replay checkout-availability -p checkout-team --from 2026-07-01 --to 2026-08-01

$ sloctl delete slo checkout-availability -p checkout-team

Teams that manage the rest of their infrastructure as Terraform prefer Nobl9's official Terraform provider over hand-applied YAML — same objects, reviewed in a pull request, applied by CI, kept as one artifact alongside the rest of the stack rather than a separate sloctl apply step run by hand.

Gotchas and failure modes

☺ Like you're 10: Almost every "why is this SLO lying to us" story comes from one of a short list of well-known traps — most of them silent, which is exactly what makes them dangerous.

The inverted numerator/denominator — silent and dangerous

Nobl9 doesn't know your service; it only knows the two queries you gave it. Swap good and total — or write good as a query that happens to always return the same number as total — and the SLO reports a permanent, plausible-looking 100% attainment with a full error budget forever. No error, no warning, no failed apply: the manifest is syntactically fine, it's just measuring the wrong thing. Because every burn-rate AlertPolicy is built on top of that same wrong number, it never fires either — the team gets silence precisely when they'd most need a page. This is the single highest-value thing to check in review before trusting a new SLO: read the good and total queries side by side and confirm good is genuinely a subset of total, not a copy of it.

Direct vs. Agent mismatch

Pointing a new Data Source at Direct when the backend is only reachable from inside a private network — or standing up an Agent for a backend that was reachable directly all along — produces the same symptom either way: the SLO shows no data, indefinitely, with no obvious error surfaced in the UI beyond "last successful fetch: never." Diagnosing it means checking network reachability from wherever the query is actually supposed to run, which is the Agent's container logs for an Agent source, or Nobl9's own connectivity check for a Direct one — not the SLO object itself, which has nothing useful to say about a query that's never successfully run.

Composite-SLO weighting mistakes

A composite SLO is a weighted roll-up of other SLOs, and an unconsidered weighting scheme produces a number that's technically correct and practically misleading — a "checkout journey" composite where one lightly-used, chronically-flaky internal service is weighted equally with the actual payment call can drag the whole composite's attainment down over an outage nobody using the checkout flow actually experienced. Treat composite weights as a design decision worth reviewing, the same way a golden-signal dashboard's panel choices deserve review, not a default to accept unexamined.

API rate limits on Direct sources at scale

A Direct Data Source means Nobl9's own infrastructure is the one calling a backend's API, on every configured SLO's schedule. An organization with a hundred SLOs querying the same CloudWatch account, each on its own poll interval, can bump into that account's own API rate limits — a problem that shows up as intermittently stale data across many SLOs at once rather than a single obvious failure, and is worth checking specifically when several unrelated SLOs against the same backend all go stale together.

Manifest sprawl and per-SLO cost

Nobl9's commercial pricing is generally shaped around SLO or Objective count, not a flat platform fee — verify the current model on Nobl9's own pricing page before budgeting, since like most SaaS pricing it's a moving target. The practical consequence is the same one Datadog's custom-metric cardinality produces for a very different reason: self-service SLO creation with no review step tends toward sprawl, and a growing count of SLOs nobody looks at is a growing bill for exactly nothing. The fix is the same governance habit that keeps a monitor fleet sane — a lightweight review before a new SLO merges, and a periodic audit that retires SLOs no one has looked at in months.

Nobl9 vs. Sloth vs. built-in vendor SLOs

☺ Like you're 10: A few different tools all promise to do the error-budget math for you — they just differ in whether they work across every backend you own, and whether you pay a monthly bill for the privilege.

The decision in practice mirrors the one Datadog's own page works through from the opposite direction: if telemetry genuinely lives in one place, that platform's built-in SLOs (or Sloth, if the one place is Prometheus) are the pragmatic default with no reason to add a second vendor. Once an org is multi-backend, or wants SLOs defined as portable specs rather than locked to whichever vendor happens to be under contract this year, a dedicated cross-backend layer like Nobl9 earns the extra line item — and reliability economics is the page that covers how to actually price that tradeoff against the alternative of nobody centralizing the math at all.

Where Nobl9 fits in the SREF blueprint

☺ Like you're 10: The exam won't quiz you on Nobl9's pricing page — it wants you to recognize "this is an SLO/error-budget tool" from a description, whether or not the name in front of you is one you've used.

The DevOps Institute SRE Foundation (SREF) exam is closed-book and tests tool categories, not vendor trivia, as SRE Tools & Automation covers in full — Nobl9 is one of the representative tools listed for the SLO/error-budget tracking row, alongside Sloth, and Service Level Objectives & Error Budgets and Monitoring & Service Level Indicators are the domains that actually get tested. Know what a dedicated, multi-backend SLO-management layer is for and how it differs structurally from a general dashboarding tool or a single-vendor built-in feature — that's the transferable knowledge; the manifest field names on this page are for the job, not the exam. See the SRE toolchain for how Nobl9 sits alongside the rest of this course's metrics, tracing, paging, and chaos categories, and Capstone Part 2 — build the monitoring & alerting for hands-on reps defining and alerting on a real SLO rather than just reading about one.