SLO Management Skill

An SLO (Service Level Objective) defines a reliability target for a service — e.g. "99.9% of requests succeed over 28 days". Use this skill to inspect SLO definitions, judge whether they are healthy, and manage their lifecycle.

CLI Commands

• All commands support -o json for structured output and -p <profile> (repeatable) for multi-profile fan-out.
• create/update read from --from-file <path>, or - for stdin (the default).
• create, update, and delete are write operations and require --yes in non-interactive / agent mode.

SLO Definition

The fields surfaced on every SLO:

Monitoring SLO Health

# All SLOs with their target and window
cx slos list -o json | jq '[.[] | {name, targetThresholdPercentage, sloType, sloTimeFrame}]'

# Inspect a single SLO in full
cx slos get <slo-id> -o json

Compare the live attainment against targetThresholdPercentage to judge whether the SLO is healthy or burning error budget. A request-based SLO measures the fraction of good events; a window-based SLO measures the fraction of good time windows. After triage, pivot to the cx-telemetry-querying skill to find the root cause of a breach in logs, spans, or metrics.

Creating and Updating SLOs

The safest way to author an SLO is to round-trip an existing one — template from the exact field shape that get returns rather than hand-writing JSON:

# Template from an existing SLO, edit, then create
cx slos get <existing-slo-id> -o json > slo.json
# Edit slo.json: change name, targetThresholdPercentage, sloType, sloTimeFrame, etc.
cx slos create --from-file slo.json --yes

# Replace an existing definition
cx slos update --from-file slo.json --yes

update and delete report the alert IDs they affect (effectedSloAlertIds), so review that list — changing or removing an SLO can disable the alerts attached to it.

Key Principles

• Check attainment vs. target, not just existence — an SLO at 99.91% against a 99.9% target has almost no error budget left and needs attention before it breaches.
• Round-trip definitions — template create/update payloads from cx slos get rather than hand-writing JSON, to keep the exact field shape the API expects.
• create/update/delete need --yes in agent / non-interactive mode.
• Watch affected alerts — update/delete return effectedSloAlertIds; deleting an SLO can silence its alerts.
• Multi-profile fan-out with -p <profile> (repeatable) to compare SLOs across environments.

Related Skills

• cx-alerts — the alert definitions that fire when an SLO's error budget burns.
• cx-telemetry-querying — investigate the logs, spans, and metrics behind an SLO breach.
• cx-cases — triage the cases that group the alert events raised against a service.