OPEN SOURCE SLO MANAGEMENT

Reliability, tied to the user journey.

Define what good looks like. Connect service level objectives to critical user journeys, then track the signals and error budgets that matter.

Pre-release MVP · Apache-2.0 · Self-hosted

CommerceSYNTHETIC PREVIEW

SERVICE LEVEL OBJECTIVE

Checkout success

Within objective
Measured SLI99.96%
SLO target99.90%
Rolling window28days
SLISLO targetLast 24 hours
Illustrative SLI compared with its SLO targetSynthetic availability fluctuates around 99.96 percent, with a brief dip below the 99.90 percent target. This is an illustration, not live telemetry.00:0012:0024:00
Error budget remaining60.0%
Illustrative workspace with synthetic values.
Built around your observability stack
  • Prometheus
  • Grafana Mimir
  • OpenTelemetry
  • PostgreSQL
  • Go

FROM USER EXPERIENCE TO SERVICE SIGNAL

Give every objective a reason.

Service metrics describe a system. Critical user journeys explain why its reliability matters. Nines connects the two explicitly.

  1. 01

    Map the journey

    Define the steps a user depends on, their owners and the SLOs that protect them.

  2. 02

    Measure the objective

    Compare observed SLI with a target, rolling window and error budget using configured Prometheus or Mimir sources.

  3. 03

    Act on budget burn

    Generate recording and two-window burn-rate rules. Review deployment to the intended tenant and ruler destination.

ONE VERSIONED CONTRACT

Reliability belongs
in version control.

SLOs and critical user journeys share a YAML API. Review changes in Git, validate offline, and apply against an explicit resource revision.

Versioned YAML
A shared nines.dev/v1alpha1 contract.
Explicit links
Journey steps refer to the SLOs they depend on.
Reviewed changes
Plan before applying. Check the expected revision.
Browse example definitions
YAML
api-availability.slo.yaml
apiVersion: nines.dev/v1alpha1
kind: ServiceLevelObjective
metadata:
  name: api-availability
  project: production
spec:
  displayName: API availability
  service: gateway
  target: 0.999
  windowSeconds: 86400
  stepSeconds: 60
  goodQuery: sum(increase(http_requests_total{code!~"5.."}[1m]))
  totalQuery: sum(increase(http_requests_total[1m]))
  policies:
    - name: fast-burn
      severity: critical
      shortWindowSeconds: 300
      longWindowSeconds: 3600
      burnRate: 14.4
      forSeconds: 120
      minCoverage: 1
    - name: sustained-burn
      severity: warning
      shortWindowSeconds: 1800
      longWindowSeconds: 21600
      burnRate: 6
      forSeconds: 300
      minCoverage: 1

TRY THE WORKFLOW

From a definition to a running SLO.

Use these examples from a source checkout or with the alpha binaries. Each workflow makes its prerequisites and changes explicit.

Run the complete Prometheus flow

Start Nines, PostgreSQL, Prometheus and a synthetic checkout service. Existing credentials and data are preserved on restart.

The verifier deliberately injects synthetic failures and can take several minutes. Prometheus is at localhost:19090; Mimir is optional.

Playground guide
Shell
# Run from a Nines source checkout with Docker running.
([ -f .env ] || python3 scripts/setup-local.py --playground) && \
  docker compose -p nines-playground -f compose.playground.yaml up --build -d

# Open http://127.0.0.1:18080 and sign in with admin / admin.
# Review and deploy the sample SLO's rules in its Rules tab.

# Optional: exercise collection, deployment, RBAC and alert recovery.
docker compose -p nines-playground -f compose.playground.yaml run --rm verify

Validate and generate rules without a server

Keep the definition in Git. Validate its contract and render recording and severity-based alert rules before connecting to any provider.

Offline validation does not check whether provider metrics exist. Generated rules are YAML output; this command does not deploy them.

CLI reference
Shell
# Build once from a source checkout, or use the alpha binary.
go build -o bin/nines ./cmd/nines

bin/nines validate --offline -f examples/api-availability.slo.yaml --agent

bin/nines rules generate --offline \
  -f examples/api-availability.slo.yaml --tenant commerce

bin/nines capabilities --offline --agent

Connect the CLI to one tenant

Use a named context to make the server and tenant explicit. API keys come from the environment; configured SSO is also supported.

A plan previews a change. Applying it is a separate action that requires permission and the expected resource revision.

Identity and tenant guide
Shell
# Use a token issued for your deployment and tenant.
export NINES_API_KEY="YOUR_TENANT_API_KEY"

nines config set-context production \
  --server https://nines.example.com --tenant commerce

nines get slos --context production --agent
nines plan --context production -f examples/api-availability.slo.yaml --agent

# Alternative: use the server's configured SSO provider.
nines login --context production --method sso

Inspect the recorded SLI and budget burn

After deploying reviewed rules, open the playground Prometheus query page. Compare observed reliability with the target across the configured windows.

Use localhost:19090/query and /rules. Prometheus's /metrics endpoint exposes its own instrumentation, not recording-rule results. Configured alerts can be inactive while traffic is healthy.

Metrics and rule destinations
PromQL
# SLO target
nines:slo_target:ratio{nines_tenant="prometheus",nines_slo="checkout-success"}

# Measured SLI for the short burn window
nines:sli:ratio{nines_tenant="prometheus",nines_slo="checkout-success",window="60s"}

# Error-budget consumption rate
nines:slo_burn_rate:ratio{nines_tenant="prometheus",nines_slo="checkout-success"}

# Active critical or warning burn alerts
ALERTS{alertname="NinesSLOBurnRate",alertstate="firing"}

Preview a change with the typed Go client

This complete example reads its connection from the environment, plans a typed SLO and requires an explicit opt-in before applying it.

Set NINES_URL, NINES_TENANT and API_TOKEN. The example only applies when NINES_APPLY=true; the plan supplies the expected revision.

Full Go example
Go
// Preview a typed SLO plan; NINES_APPLY=true applies it to the configured tenant.
package main

import (
	"context"
	"fmt"
	"log"
	"os"
	"time"

	v1 "github.com/ishantanu/nines/api/v1alpha1"
	"github.com/ishantanu/nines/client"
)

func main() {
	c, err := client.New(client.Config{URL: os.Getenv("NINES_URL"), Tenant: os.Getenv("NINES_TENANT"), Token: os.Getenv("API_TOKEN")})
	if err != nil {
		log.Fatal(err)
	}
	slo := v1.NewSLO("api-availability", "production", v1.SLOSpec{DisplayName: "API availability", Service: "gateway", Target: .999, WindowSeconds: 86400, StepSeconds: 60, GoodQuery: `sum(increase(http_requests_total{code!~"5.."}[1m]))`, TotalQuery: `sum(increase(http_requests_total[1m]))`})
	ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
	defer cancel()
	plan, err := c.Plan(ctx, slo)
	if err != nil {
		log.Fatal(err)
	}
	fmt.Printf("%s %s (expected revision %d)\n", plan.Action, slo.Metadata.Name, plan.ExpectedRevision)
	if os.Getenv("NINES_APPLY") != "true" {
		fmt.Println("Review the plan; set NINES_APPLY=true to apply.")
		return
	}
	revision, err := c.Apply(ctx, slo, plan.ExpectedRevision)
	if err != nil {
		log.Fatal(err)
	}
	fmt.Printf("Applied revision %d, digest %s\n", revision.Revision, revision.Digest)
}

Give an agent tenant-scoped read access

Add the stdio adapter to an MCP-compatible client. Use a viewer-role token and an explicit tenant; tool writes are disabled by default.

The adapter needs a running Nines server. Store the real token in your client's private configuration or secret mechanism, outside source control.

Agent and skill integration
JSON
{
  "mcpServers": {
    "nines": {
      "command": "/path/to/nines-mcp",
      "args": [
        "--server", "https://nines.example.com",
        "--tenant", "commerce"
      ],
      "env": {
        "API_TOKEN": "YOUR_TENANT_VIEWER_TOKEN"
      }
    }
  }
}

CLI, SDK AND MCP

Give agents context.
Keep changes reviewable.

The same resource contracts sit behind the UI, CLI, Go client and MCP adapter. Model assistance is optional; measurement and validation remain deterministic.

A CLI that works offline

Validate definitions and generate rules without a server. Use structured JSON output in scripts and deterministic skills.

Tenant-scoped MCP tools

Expose the HTTP resource contracts through a stdio MCP adapter, using explicit server and tenant contexts.

Read the CLI and skills guide

START WITH THE LOCAL DEMO

Start with a
working workspace.

Run Nines with synthetic SLOs and critical user journeys. No provider credentials or model account needed.

Requires Go 1.27.3 or later.

Terminal
git clone https://github.com/ishantanu/nines.git
cd nines
go run ./cmd/server -demo

Open http://127.0.0.1:8080 and sign in with admin / admin. Demo data resets on restart. Keep the demo on loopback.

Set up a persistent workspace

BUILT IN THE OPEN

Release status and scope.

Nines is a pre-release MVP under active development. Expect regular features and fixes. Core SLO and critical user journey management is the release focus. Intent workflows, session replay and the Kubernetes reconciler are experimental.