User manual
Four steps. One ZIP. Everything your Prometheus stack needs to enforce an SLO.
Step 1 — Service & SLI
Name the service you want to measure and pick the SLI kind that matches how it exposes its health. This determines the entire PromQL structure of the generated rules.
- Service name — Used as a prefix in all generated metric names. Keep it short and slug-friendly (e.g. api-gateway, checkout, payment-svc).
- SLI type — Drives the PromQL formula. Each kind computes good events / total events differently — see the reference section below.
- Calculation method — Request-based counts individual events. Window-based evaluates a metric across a fixed time window — required for probes and freshness gauges.
- Quick-start presets — Five preset cards on the home page pre-fill all step 1 fields. Use them to skip manual entry when your service fits a standard pattern.
Step 2 — Metric wiring
Point at the source Prometheus metric, filter it down with labels if needed, and choose how HTTP status codes are classified good/bad.
- Prometheus metric — The Prometheus metric this SLI is built on. Must match /^[a-zA-Z_:][a-zA-Z0-9_:]*$/ — no spaces, no special characters.
- Live PromQL preview — As you type the metric name, the recording rule expression updates live in the side panel. No need to wait until step 4 to see what you're generating.
Step 3 — Objective & window
Pick your target percentage, choose how long the measurement window should be, and decide whether the SLO applies around the clock or only during business hours.
- Objective (%) — Anything between 50 and 99.999 works. 100 % is rejected — it leaves zero error budget, which makes the SLO meaningless.
- Window duration — 28–30 days is the standard. Go shorter than 14 days and the burn rate math gets noisy — small spikes burn the budget fast.
- Business hours regime — 24/7 measures everything. Standard is Mon–Fri 8am–6pm. Extended adds Saturday and widens the window. Custom lets you define your own schedule.
- Custom burn rate policies — The Advanced section below the Business Hours fieldset shows four editable rows pre-filled with Google SRE defaults. Change them if your team uses different alert cadences.
First time? Start with 99.9 % over 28 days in 24/7 mode. You can always tighten it once you know what your service actually delivers.
Step 4 — Review & download
This screen shows everything before you commit: your SLI, the objective, the window, the four burn-rate policy pairs, and the error budget in minutes. Read it. If something looks off, go back.
Hit "Download ZIP Bundle" and the artifacts download immediately. Pro plan or above required — each download uses one credit. Check your profile to see how many you have left.
SLI kinds reference
The kind you pick determines everything about the PromQL formula. It is not just a label — it changes the math. Here is what each one means.
The fraction of HTTP requests that came back with a success code — 2xx or 3xx. This is the go-to SLI for web APIs, microservices, and anything behind a load balancer.
Example metric
The fraction of requests served under your latency threshold. You need a histogram metric for this — the threshold maps to one of the le bucket values.
Example metric
The fraction of requests that came back as errors, tracked by a status or result label. Think of it as the inverse of Availability. Pick this one when your service exposes error codes directly — gRPC is the classic example.
Example metric
Measures whether your service keeps processing above a minimum volume threshold. Correctness and latency are not the point here — volume is. Message queue consumers, stream processors, that kind of thing.
Example metric
A 0/1 success metric from a blackbox check — HTTP, TCP, or DNS. It uses avg_over_time() to evaluate the probe across a fixed window rather than counting individual requests. The right choice for external uptime monitoring.
Example metric
The fraction of responses served at full quality — no degraded fallbacks, no partial data, no missing fields. Use this when your service can technically succeed but hand back a worse version of what was asked for.
Example metric
The fraction of outputs that are actually correct. Works best for batch jobs, data pipelines, and ML inference — anywhere you can validate the output after the fact.
Example metric
The fraction of records you expected to process that were actually processed. For ETL pipelines, crawlers, ingestion jobs — any workload where there is a known universe of items and a deadline to handle them.
Example metric
The fraction of write operations confirmed as durable. The failure mode here is data loss, not downtime. Object stores, databases, replication systems — that is where this lives.
Example metric
How often your data was actually fresh, expressed as a fraction of time. It uses a binary gauge — 1 means fresh, 0 means stale — averaged over a rolling window. Good fit for data pipelines, caches with TTLs, or any reporting job where stale data is the real risk.
Example metric
ZIP bundle contents
- prometheus/
- recording-rules.yaml + alerting-rules.yaml, both validated by promtool before packaging.
- alertmanager/
- routes.yaml with routing rules, plus page and ticket notification templates ready to drop into Alertmanager.
- grafana/
- Two Grafana dashboards: an SLO overview and a live burn-rate panel. Import them directly.
- docs/
- Runbooks for page and ticket alerts, an SLO definition doc, and an error budget policy — all in Markdown, ready to commit.
Deploying your bundle
The README.md inside the ZIP has full instructions for Kubernetes, Prometheus Operator, and GitOps provisioning. Below is the quick path for a standard bare-metal Prometheus stack.
-
01 — 1. Validate first
Run promtool against both YAML files before touching your server. The bundle ships with unit tests — run those too.
make check && make test -
02 — 2. Load recording rules
Copy recording-rules.yaml to your Prometheus rules directory and reload. The alerting rules reference these pre-computed metrics — they must exist before the alerts can evaluate.
cp prometheus/recording-rules.yaml /etc/prometheus/rules/ curl -X POST http://localhost:9090/-/reload -
03 — 3. Load alerting rules
Copy alerting-rules.yaml to the same directory and reload again. Four multi-burn-rate policies are generated: two page-severity and two ticket-severity.
cp prometheus/alerting-rules.yaml /etc/prometheus/rules/ curl -X POST http://localhost:9090/-/reload -
04 — 4. Configure Alertmanager
Copy the .tmpl files to your Alertmanager templates directory. Merge the contents of routes.yaml into your alertmanager.yml under route.routes — it is a routing subtree, not a full config.
cp alertmanager/*.tmpl /etc/alertmanager/templates/ amtool check-config /etc/alertmanager/alertmanager.yml curl -X POST http://localhost:9093/-/reload -
05 — 5. Import Grafana dashboards
Upload the two .json files via Dashboards → New → Import in the Grafana UI, or use the Grafana API. The provisioning/ folder contains ready-to-use provisioning files for GitOps setups.
Prometheus requires --web.enable-lifecycle for the hot-reload endpoint to work. Without it, a full restart is needed after copying rules.
The README.md inside the ZIP also covers Prometheus Operator (PrometheusRule CRD), Grafana Alloy business-hours relabeling, and CI validation via the included GitHub Actions workflow.
How nines compares
Wondering how nines stacks up against other SLO tools? See side-by-side feature comparisons.