/service-reliability

name: observability-service-reliability
description: >
  Design and operate service reliability targets in Elastic Observability: choose
  an SLI type and a defensible target, pick a time window and budgeting method, create
  and maintain SLOs through the Kibana API, attach burn-rate alert rules, and decide
  when an SLO is the wrong instrument and a threshold rule, anomaly job, or synthetics
  monitor is right. Use when defining or reviewing SLOs and error budgets, tuning
  burn-rate alerting, reducing alert noise, or setting up availability monitoring
  for a user-facing endpoint.
compatibility: >
  Requires Kibana 8.x or 9.x with a matching Elasticsearch cluster (self-managed,
  Elastic Cloud Hosted, or Serverless) and the Observability solution enabled. The
  cluster must have nodes carrying both the `transform` and `ingest` roles, since
  every SLO is backed by a continuous transform. Needs the `elastic` CLI >= 0.2 with
  `stack kb` and `stack es` support. Synthetics SLIs additionally require the Synthetics
  app and at least one configured monitor location.
metadata:
  author: elastic
  version: 0.4.1
  universal: true

Service Reliability

Design reliability targets that people will actually act on, then operate them. This skill covers the judgment before the API call — which service-level indicator fits the data you have, what target is achievable rather than aspirational, whether an SLO is even the right instrument — and then the mechanics of creating, alerting on, resetting, and retiring SLOs through the Kibana API.

Reliability instruments are not interchangeable. An SLO measures a user-visible outcome against a spendable budget; a threshold rule fires on a raw condition; an anomaly job finds deviations where no fixed threshold exists; a synthetics monitor is the only one of the four that can see a service that has stopped emitting telemetry entirely. Choosing wrong produces alerts that are technically correct and operationally useless. For diagnosing a service that is already degraded, and for the incident workflow itself, use the **observability-sre-triage** skill; for general rule lifecycle mechanics use the **kibana-alerting-rules** skill.

<!-- begin-partial: preamble -->

Environment Configuration

This skill executes Elasticsearch operations through the `elastic` CLI. If the [`elastic` CLI](https://github.com/elastic/cli#configuration) is not installed, tell the user what it is needed for. Do not guess credentials, call the HTTP API directly, or attempt other workarounds.

This skill references operations in HTTP-shorthand form (e.g., `GET /`, `GET /_cat/indices`, `GET /{index}/_mapping`, `GET /{index}/_settings/index.mode`, `POST /_query`). The [Operations](#operations) table at the end of this document maps each shorthand to the equivalent `elastic` CLI command — always use the CLI rather than calling the HTTP API directly.

<!-- end-partial: preamble -->

Analysis without cluster access

The CLI check above gates _querying the cluster_ — it does not gate analysis. When the user has already supplied the evidence in their question (metric values, counts, status reasons, log lines, alert payloads, configuration), reason from that evidence and deliver the conclusion.

When you genuinely do need data the user has not provided, still say what you would check and how — name the specific query, index, and field that would settle the question — and then ask for CLI setup. An answer that names the check is useful without a cluster; one that only asks for setup is not.

SLO and alerting operations run against Kibana and use the `kbn:` prefix (for example, `POST kbn:/api/observability/slos`); data validation runs against Elasticsearch with a bare path (for example, `POST /_query`). Kibana SLO commands are space-scoped — pass the space explicitly. For non-default spaces the HTTP path becomes `kbn:/s/<space_id>/api/observability/slos`.

Full request-body schemas for every SLI type live in [references/slo-api-schemas.md](references/slo-api-schemas.md), the burn-rate rule schema in [references/burn-rate-rules.md](references/burn-rate-rules.md), and curated official documentation in [references/documentation.md](references/documentation.md).

Jobs to be done

• Translate a reliability concern into the right instrument: SLO, burn-rate rule, threshold rule, anomaly job, or

synthetics monitor

• Choose an SLI type for a given service and data shape, and validate the underlying fields before committing
• Set a target, time window, and budgeting method that are defensible against measured history
• Decide whether to group an SLO, and refuse high-cardinality grouping
• Create, verify, update, reset, disable, and delete SLOs
• Attach burn-rate alert rules with fast-burn and slow-burn windows routed to different severities
• Keep the alerting surface signal-dense: remove duplicate coverage, snooze instead of disable, delete unactionable

rules

• Monitor availability of user-facing endpoints with synthetics and feed that into an availability SLI

Output discipline

Applies to every response produced under this skill.

• **Commit to the best-supported conclusion.** Recommend one SLI design and defend it. Do not enumerate every SLI type

with equal weight and leave the choice to the user — that is not a recommendation, it is a menu.

• **State the target and window you chose, and why, once.** Do not restate the justification per bullet.
• **Do not invent field names.** Verify every field against the mapping before writing it into an indicator. If a field

cannot be confirmed, say so and stop; a plausible-looking field name is worse than an admitted gap.

• **Do not speculate past the evidence.** If the measured history does not support a target, say what it does support.
• **Report absence as absence.** Zero events means the data is missing or the service is not emitting; it never means

the service is healthy. An SLI ratio computed over zero total events is undefined,