Skip to content
RunWhen

SLX Configuration

An SLX (Service Level Expectation) bundles everything the RunWhen Platform needs to monitor, measure, and act on a piece of your infrastructure. Each SLX is defined as a set of Kubernetes Custom Resources that are managed through Git and synced into the platform automatically.

Workspace Studio — SLXs organized by platform, cluster, and namespace

This section covers the configuration reference for each SLX component:

ComponentWhat It DoesConfig Reference
SLIs (Indicators)Run scripts on a schedule to measure health — returning a numeric metric that is stored and evaluated for alertingSLI Configuration
SLOs (Objectives)Define error budgets using multi-window burn-rate alerting against the SLI metricSLO Configuration
Tasks & RunbooksDiagnostic or remediation scripts that run on demand, on a schedule, or in response to alertsTask & Runbook Configuration

How SLX Components Relate

SLX
├── SLI  →  runs on schedule  →  stores metric for alerting
│    ├── spec.alerts        →  threshold alerts (warning / ticket / page)
│    └── spec.alertConfig   →  auto-runs tasks when metric < 1.0
│
├── SLO  →  tracks error budget against the SLI metric
│    └── burn-rate alerts (page / ticket)
│
└── Runbook  →  contains tasks (Robot Framework)
     ├── configProvided     →  environment variables
     ├── secretsProvided    →  workspace secrets
     └── requirements       →  Python dependencies

Configuration Lifecycle

SLX components follow a GitOps workflow:

  1. Define — SLX YAML files are committed to the workspace Git repository
  2. Sync — changes are detected and applied to the platform automatically
  3. Process — the platform generates alert rules, schedules SLI runs, and resolves CodeBundles
  4. Serve — configuration is available through the API and UI

Changes to SLX configuration should always be made through Git. Direct modifications outside of Git will be overwritten on the next sync cycle.