Skip to content
RunWhen

SLI Authoring

A Service Level Indicator (SLI) is a lightweight, periodic health check that produces a 0–1 score. Most SLIs use binary checks (0 = failing, 1 = passing) aggregated as a mean, but SLIs can push any float in the 0–1 range — for example, a latency-based SLI might return 0.85 to indicate partial health. When the score drops below a configured alert threshold, the associated runbook is triggered automatically.

When to build an SLI

Bundle typeExamplesSLI approach
Health / monitoring*-healthcheck, *-health, *-monitorIn-repo sli.robot with a dedicated SLI template
Operational / triage*-ops, *-triage, *-restart, *-remediateCron-scheduler SLI that periodically triggers the runbook
Chaos / one-off*-chaos-*, manual remediationTypically no SLI (runbook is on-demand only)

If the bundle answers “is this resource healthy right now?”, it needs an in-repo SLI. If it answers “perform this action”, use the cron-scheduler pattern.

Design principles

  1. Lightweight — complete in under 30 seconds
  2. Frequent — runs every 30–600 seconds (intervalSeconds in the template, typically 180 for namespace-level, 300–600 for resource-level)
  3. Read-only — never modify resources; use access:read-only tags
  4. Idempotent — safe to run continuously without side effects
  5. Binary or fractional — most checks produce 0 (failing) or 1 (passing), aggregated as an arithmetic mean for the final score. SLIs can also push fractional values (e.g. 0.85) for partial-health signals like latency percentiles
  6. Configurable thresholds — use RW.Core.Import User Variable with sensible defaults so each deployment can tune sensitivity
  7. Safe error handling — wrap JSON parsing in TRY/EXCEPT; default to a reasonable value (typically 0 for strict, 1 for optional checks)

RW_LOOKBACK_WINDOW — the big gotcha

RW_LOOKBACK_WINDOW controls how far back time-windowed SLI signals look (failed-build ratio, recent activity, etc.). It is not the same as the deep investigation window used by runbooks.

ContextWho sets itTypical valuePurpose
SLI (sli.robot)Platform (from intervalSeconds)~scrape interval × 1.5Current-state gauge
Runbook (runbook.robot)configProvided + Import User Variable24h, 7d, 30dDeep investigation after SLO breach

Do not put RW_LOOKBACK_WINDOW in the SLI template configProvided. If you hard-code 24h there, the SLI will treat failures as in-window for that entire period and stay unhealthy long after recovery.

In sli.robot, import it as a platform variable with a fallback for local dev:

TRY
    ${RW_LOOKBACK_WINDOW}=    RW.Core.Import Platform Variable    RW_LOOKBACK_WINDOW
EXCEPT
    ${RW_LOOKBACK_WINDOW}=    Set Variable    2700
END
${RW_LOOKBACK_WINDOW}=    RW.Core.Normalize Lookback Window    ${RW_LOOKBACK_WINDOW}    2
Set Suite Variable    ${RW_LOOKBACK_WINDOW}    ${RW_LOOKBACK_WINDOW}

The ro dev runner simulates SLI context by unsetting RW_RUNREQUEST_ID and exporting RW_LOOKBACK_WINDOW defaulting to intervalSeconds × 1.5 (override with RW_SLI_INTERVAL_SECONDS, default 1800 → 2700).

SLI template checklist

When authoring the *-sli.yaml template:

  • pathToRobot: codebundles/<bundle>/sli.robot
  • intervalStrategy: intermezzo
  • intervalSeconds: aligned to desired scrape interval
  • configProvided: user variables only (org, namespace, thresholds) — no RW_LOOKBACK_WINDOW
  • alertConfig with persona: eager-edgar and sessionTTL so SLO breach triggers the runbook