SloK

Kubernetes-native SLO operator for defining, automating, and backtesting service reliability.

Installation · SLOs · CLI · Dashboard · Docs

• Defines SLOs as Kubernetes custom resources.
• Generates Prometheus recording rules for SLI error rate, error budget, and burn rate.
• Generates burn-rate and error-budget alerts using PrometheusRule resources.
• Tracks current objective status in the Kubernetes resource status.
• Supports built-in SLI templates and manual PromQL metric selectors.
• Backtests SLO YAML files before they are applied to the cluster.
• Supports SLO composition for higher-level user journeys.
• Correlates SLO degradation with recent Kubernetes changes.
• Ships with an optional web dashboard for browsing SLOs and historical trends.

• Installation
• SLO definitions
• CLI backtesting
• Dashboard
• Alerting and recording rules
• SLO composition
• Event correlation
• Development
• Full documentation index

Install SloK with Helm:

helm install slok charts/slok \
  --namespace slok-system \
  --create-namespace \
  --set prometheus.url=http://prometheus-kube-prometheus-prometheus.monitoring.svc:9090

Create an SLO:

apiVersion: observability.slok.io/v1alpha1
kind: ServiceLevelObjective
metadata:
  name: checkout-availability
  namespace: default
spec:
  displayName: Checkout Availability
  objective:
    name: availability
    target: 99.9
    window: 30d
    sli:
      query:
        totalQuery: http_requests_total{service="checkout"}
        errorQuery: http_requests_total{service="checkout",status=~"5.."}

Apply it:

kubectl apply -f slo.yaml

Check status:

kubectl get slo
kubectl get slo checkout-availability -o yaml

SloK includes a CLI for testing an SLO against historical Prometheus data.

Build the CLI locally:

make build-cli

Backtest an SLO that has already been applied to the cluster:

bin/slok backtest \
  --namespace default \
  --name checkout-availability \
  --prometheus-url http://localhost:9090

This mode uses existing SloK recording rules in Prometheus.

You can also backtest an SLO YAML before applying it:

bin/slok backtest \
  -f slo.yaml \
  --pre-apply \
  --prometheus-url http://localhost:9090

Pre-apply backtesting reads:

spec:
  objective:
    sli:
      query:
        totalQuery: ...
        errorQuery: ...

and queries Prometheus directly, so the SLO does not need to exist in the cluster yet.

You can compare multiple target values with what-if mode:

bin/slok backtest \
  -f slo.yaml \
  --pre-apply \
  --targets 99,99.5,99.9,99.95 \
  --prometheus-url http://localhost:9090

Current limitation: pre-apply backtesting supports manual totalQuery / errorQuery SLIs. Template-based pre-apply backtesting is planned.

SloK can deploy an optional dashboard alongside the operator.

The dashboard lists SLOs, shows objective status and error budget, and provides historical trend charts backed by Prometheus.

Enable it through the Helm chart:

helm install slok charts/slok \
  --namespace slok-system \
  --create-namespace \
  --set dashboard.enabled=true \
  --set dashboard.ingress.enabled=true \
  --set dashboard.ingress.className=nginx \
  --set dashboard.ingress.hosts[0].host=slok-dashboard.local \
  --set dashboard.prometheus.url=http://prometheus-kube-prometheus-prometheus.monitoring.svc:9090

The dashboard is intentionally authentication-free. Put it behind your existing Ingress authentication, VPN, oauth2-proxy, or internal network controls.

An SLO contains one objective. The objective defines the target, the rolling window, and the SLI used to measure reliability.

Manual SLIs use two Prometheus metric selectors:

• totalQuery: total events
• errorQuery: failed events

apiVersion: observability.slok.io/v1alpha1
kind: ServiceLevelObjective
metadata:
  name: payment-api-availability
spec:
  displayName: Payment API Availability
  objective:
    name: availability
    target: 99.9
    window: 30d
    sli:
      query:
        totalQuery: http_requests_total{service="payment-api"}
        errorQuery: http_requests_total{service="payment-api",status=~"5.."}

Queries should be metric selectors only. Do not include sum(), rate(), or increase(). SloK wraps the selectors when generating recording rules.

Templates avoid writing raw PromQL for common SLI patterns.

apiVersion: observability.slok.io/v1alpha1
kind: ServiceLevelObjective
metadata:
  name: payment-api-availability
spec:
  displayName: Payment API Availability
  objective:
    name: availability
    target: 99.9
    window: 30d
    sli:
      template:
        name: http-availability
        labels:
          service: payment-api

Available templates:

For each SLO, SloK generates Prometheus recording rules similar to:

slok:sli_error_rate:5m
slok:sli_error_rate:1h
slok:sli_error_rate:6h
slok:sli_error_rate:3d
slok:sli_error_rate:7d
slok:sli_error_rate:30d
slok:error_budget_target
slok:burn_rate:5m
slok:burn_rate:1h
...

Burn-rate alerts follow the multi-window, multi-burn-rate approach from the Google SRE Workbook.

When enabled, SloK can create default alerts for:

• fast burn / active outage
• medium burn / degraded behavior
• slow burn / steady erosion
• exhausted error budget

Custom error-budget and burn-rate alerts can also be configured per SLO.

SloK can combine multiple SLOs into a higher-level objective with SLOComposition.

This is useful for user journeys where reliability depends on several services.

Supported composition strategies:

Example:

apiVersion: observability.slok.io/v1alpha1
kind: SLOComposition
metadata:
  name: checkout-flow
spec:
  target: 99.9
  window: 30d
  objectives:
    - name: frontend
      ref:
        name: frontend-availability
    - name: payments
      ref:
        name: payments-availability
  composition:
    type: AND_MIN

SloK can correlate burn-rate spikes with recent Kubernetes changes such as Deployment updates, ConfigMap changes, Secret changes, and relevant Events.

When a spike is detected, it creates an SLOCorrelation resource with candidate causes and confidence levels.

kubectl get slocorr
kubectl get slocorr <name> -o yaml

An optional Groq integration can refine correlation summaries when GROQ_API_KEY is configured. Without it, SloK uses its built-in rule-based summary.

helm install slok charts/slok \
  --namespace slok-system \
  --create-namespace

Useful values:

For local development:

kubectl apply -k config/default

# Run the controller locally against your current kubeconfig
make run

# Build the operator
make build

# Build the CLI
make build-cli

# Run tests
make test

# Run lint
make lint

# Build an operator image
make docker-build IMG=ghcr.io/slok-operator/slok:dev

• Pre-apply backtesting currently supports manual totalQuery / errorQuery SLIs, not template-based SLIs.
• WEIGHTED_ROUTES composition is alpha and may change.
• One operator instance is expected per cluster.
• The dashboard does not implement authentication itself.

Apache License 2.0. See LICENSE for details.