o11y-slo-setup

name: o11y-slo-setup description: Interactive guide for creating SLOs from discovered APM and metric data — identifies candidates, lets user configure targets, and creates SLOs.

O11Y SLO Setup Workflow

Guide the user through creating Service Level Objectives based on their available data.

Trigger

Use when the user asks to:

• "Create SLO"
• "Set up SLOs"
• "Service level objectives"
• "SLO targets"
• "Availability SLO"
• "Latency SLO"

Also activates on keywords: "SLO", "service level", "burn rate", "error budget", "SLI", "availability target"

Do NOT use when:

• "Create dashboard" (→ use o11y-service-dashboard)
• "Full monitoring setup" (→ use o11y-full-setup)

Steps

0. Get Cluster Context

Call get_cluster_context to get cached cluster awareness — version, health, installed features, and SLO capabilities. This confirms that the SLO feature is available in the Kibana deployment.

1. Discover Data

Call discover_o11y_data to find APM services and metrics that can support SLOs.

2. Identify SLO Candidates

Call get_data_summary with format: "json" to get SLO recommendations.

Present each candidate:

• APM Latency SLOs: For each service with transaction data — "Service X: p95 latency < threshold, target 99.5%"
• APM Availability SLOs: For each service with error data — "Service X: availability target 99.9%"
• Custom Metric SLOs: For any numeric metrics suitable as SLIs

3. User Decision Point — Select SLOs

Ask the user:

• Which SLO candidates to create (numbered list, allow "all")
• For each selected SLO, confirm or adjust:
  • Name (suggest based on service and indicator type)
  • Target percentage (show recommended default)
  • Time window (suggest 30d rolling)
  • Any tags to apply

4. Check Existing SLOs

Call kibana_api with GET /api/observability/slos to check for duplicates. If any existing SLOs overlap with selections, warn the user and ask whether to skip or create anyway.

5. Create SLOs

For each approved SLO, call kibana_api with POST /api/observability/slos and the configured parameters as the request body.

Report each created SLO:

• Name and ID
• Indicator type and target
• Kibana URL to view

6. Summary

Present:

• Total SLOs created
• Current status of each (if available from creation response)
• Suggested next steps: monitor burn rates, set up burn rate alerts, create an SLO dashboard

7. Create Burn Rate Alerts (Optional)

For each created SLO, offer to set up burn rate alerts using create_alert_rule. Burn rate alerts trigger when the error budget is being consumed faster than expected, giving early warning before an SLO breach.

Tools Used

• get_cluster_context — cached cluster awareness (version, health, capabilities)
• discover_o11y_data — discover APM services and metrics for SLO candidates
• get_data_summary — generate SLO recommendations
• kibana_api — list existing SLOs (GET /api/observability/slos) and create new ones (POST /api/observability/slos)
• create_alert_rule — create burn rate alerts for SLOs

API References

• elastic://docs/api/kibana — Kibana REST API reference for SLO endpoints (/api/observability/slos)

Prerequisites

• ES_URL and ES_API_KEY configured
• SLO feature enabled in Kibana (Observability → SLOs)
• APM data or custom metrics flowing

Interactive Dashboard

Interactive Dashboard: When using Claude Desktop or other ext-apps hosts, slo_dashboard renders an interactive SLO monitoring view with burn rate gauges and error budget tracking, and slo_forecaster projects SLO compliance with confidence intervals. In Cursor/CLI, both return markdown.

Related Skills

• o11y-full-setup — complete observability setup including dashboards and SLOs
• o11y-service-dashboard — create service dashboards to complement SLO monitoring