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

Command	Purpose
`cx slos list`	List all SLO definitions
`cx slos get <id>`	Get a single SLO by ID
`cx slos create --from-file <path>`	Create an SLO from a JSON definition [requires `--yes`]
`cx slos update --from-file <path>`	Replace an SLO definition from JSON [requires `--yes`]
`cx slos delete <id>`	Delete an SLO [requires `--yes`]

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:

Field	Meaning
`name`	Human-readable SLO name
`description`	Optional description
`targetThresholdPercentage`	The objective, e.g. `99.9`
`sloType`	`SLO_TYPE_REQUEST` (request-based) or `SLO_TYPE_WINDOW` (window-based)
`sloTimeFrame`	Rolling window, e.g. `SLO_TIME_FRAME_7_DAYS`, `SLO_TIME_FRAME_28_DAYS`
`productType`	The pillar the SLO is computed from, e.g. `SLO_PRODUCT_TYPE_APM`

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.

cx-slos