Slo Check Status

SLO Status Checker

Check SLO health, budget consumption, and trends. Route to investigation or optimization as needed.

Core Principles

1. Use gcx commands — do not call Grafana APIs directly
2. Trust the user's expertise — no hand-holding or excessive explanation
3. Use -o json for agent processing, default format for user display
4. Show graphs for time-series data (timeline commands default to graph output)

Workflow

Step 1: Overview or Specific SLO

If the user asks about all SLOs (no specific UUID):

gcx slo definitions list

This shows UUID, name, target objective, window, and status for all SLOs.

Then get the health summary:

gcx slo definitions status

This shows SLI, error budget, and health status for all SLOs in a table.

If the user asks about a specific SLO (UUID or name provided):

gcx slo definitions status <UUID> -o wide

The -o wide output includes additional columns: BURN_RATE, SLI_1H, and SLI_1D, which give a richer picture of recent performance.

Step 2: Interpret Status Values

NODATA handling: Recording rule metrics may not be available if the destination datasource is misconfigured or recording rules are not evaluating. Note this to the user and suggest checking the destination datasource configuration.

Step 3: Timeline (Conditional)

Show the timeline when:

• The user asks about trends or historical data
• Any SLO shows BREACHING status

All SLOs timeline:

gcx slo definitions timeline --from now-7d --to now

Specific SLO timeline:

gcx slo definitions timeline <UUID> --from now-7d --to now

Use --since as a shorthand when a single duration is more natural:

gcx slo definitions timeline <UUID> --since 7d

The timeline command renders a graph by default — this is the preferred output for users.

Adjust the time range based on the SLO window:

• 7d window SLO → use --from now-7d --to now
• 28d or 30d window SLO → use --from now-28d --to now

The window you request is not necessarily the history you have: on a young stack or a recently created SLO, a 28d query may return only a few days of points. Check the timestamp of the earliest returned point, report the actual observed span alongside the requested window, and scope any whole-window claims to the data you actually saw — "steady for the 2 days of available history (28d window requested)", not "steady for the entire 28-day window".

Step 4: SLO Reports Status (Conditional)

When the user asks about SLO reports or wants combined SLO health from the reports subsystem:

gcx slo reports status

Or for a specific SLO:

gcx slo reports status <UUID>

Step 5: Route to Investigation or Optimization

BREACHING SLOs: After showing the timeline, suggest slo-investigate:

SLO <name> is BREACHING (SLI: , objective: ). For a deep-dive investigation — raw metrics, dimensional breakdown, alert rules — use the slo-investigate skill.

User asks about improvements: Route to slo-optimize:

For trend analysis, objective tuning recommendations, and alerting sensitivity review, use the slo-optimize skill.

Output Format

All-SLOs overview:

SLOs: <total> total, <n> OK, <n> BREACHING, <n> NODATA

[Table from gcx slo definitions status]

[If any BREACHING: show timeline graph]
[If BREACHING: suggest slo-investigate for each BREACHING SLO]

Specific SLO status:

SLO: <name>
Status: <OK|BREACHING|NODATA>
SLI: <value> (objective: <value>, window: <value>)
Error budget remaining: <value>
Burn rate: <value>
SLI_1H: <value> | SLI_1D: <value>

[If trend requested or BREACHING: show timeline graph]
[Routing suggestions as applicable]

Use minimal formatting. Lead with the status and key metrics. No excessive bold text.

Error Handling

Collect all errors and report at the end of the workflow — do not interrupt the workflow for non-fatal errors.