The short version: you paste five prompts into your AI coding agent, one at a time. The agent does the work. After each prompt, you open Dash0 and check one thing. At the end, your service has an SLO, alerts that tell you when it's in trouble, and a marker for every deploy.
It works with any language, any infrastructure-as-code and any CI, because every prompt tells the agent to read your code first.
Get the prompts here: five-prompt guide. This post walks through what each prompt does and what you should see in Dash0. Every screenshot below comes from SLO Coach, a real app we built and monitor in Dash0.
What is an SLO?
An SLO (service level objective) is a promise about how often your service works.
For example: "99.5% of requests succeed over 28 days."
That leaves 0.5% of requests that are allowed to fail. That allowance is your error budget. Think of it like a monthly data plan: you can use some, but you don't want to run out.
Burn rate is how fast you're using the budget. A burn rate of 1 means you'll use it up exactly at the end of the 28 days. A burn rate of 10 means you're using it 10 times too fast.
Before you start: get 3 things from Dash0
You need three things. If you don't have a Dash0 account yet, start a free trial at dash0.com/sign-up.
- One auth token. Ask an org Admin to create it under Settings > Auth Tokens. Give it All permissions on the dataset you'll use. That one token works for everything in this guide.
- Two addresses (endpoints). Copy them from Settings > Endpoints: the OTLP/HTTP ingress host (where your telemetry goes) and the API host (where the SLO goes). Mixing these two up is the most common reason nothing shows up.
- A dataset. The Default dataset works. Use the same dataset for everything.
Keep your token safe. Put the values in a .env file that's listed in .gitignore, and keep the token in a password manager so the agent never sees it.
Tip for production: later, you can split the token in two: an ingest-only token for your app and CI, and the All-permissions token just for creating SLOs.
Start your agent
Open your AI coding agent (Claude Code, Cursor, Windsurf, Copilot CLI or similar) in the folder where your app lives. If your infrastructure or your CI pipeline live in other folders, add those too.
Paste the guide's opening message first. The agent will ask you where everything lives, and it will use the same three names everywhere: service.name, service.namespace and service.version. Every step after this depends on those names matching.
Step 1: Add OpenTelemetry to your app
What you paste: prompts 1a and 1b from the guide.
What the agent does:
- Finds your language and framework, and adds the official OpenTelemetry setup for it.
- If your app already has some OpenTelemetry, it cleans it up instead of adding a second copy.
- Sets the same names on the deployed app in your infrastructure code.
Good to know: the token comes from the secret store your platform already uses, never from a Terraform variable.
Step 2: Send data to Dash0 and check it arrived
What you paste: prompt 2.
What the agent does: points your app at Dash0, sends about 20 test requests (including one that fails on purpose), and checks that they arrived.
What you should see: open Services in Dash0 and click your service. You should see requests, errors and duration.
If you see nothing: check that you used the ingress host (not the API host) and the right dataset.
Step 3: Create the SLO
What you paste: prompt 3.
What the agent does: writes a small YAML file that describes your SLO and sends it to Dash0. You don't write any queries yourself. Dash0 does the math.
The rule is simple:
- Good requests = requests that didn't fail.
- All requests = every request.
- Target = 99.5% of requests should be good.
What you should see: open SLOs, click your new SLO, then the Settings tab. It shows exactly what's being counted.
Here's the real file behind it:
apiVersion: openslo.com/v1
kind: SLO
metadata:
name: slo-coach-availability
labels:
dash0.com/origin: slo-coach-availability
spec:
description: 99.5% of requests to the SLO Coach web app succeed without a server error, measured over the last 28 days.
service: "slo-coach/slo-coach"
budgetingMethod: Occurrences
timeWindow:
- duration: 28d
isRolling: true
indicator:
metadata:
name: slo-coach-availability
spec:
ratioMetric:
counter: true
good:
metricSource:
type: Prometheus
spec:
query: '{otel_metric_name="dash0.spans", service_namespace="slo-coach", service_name="slo-coach", deployment_environment_name="production", otel_span_kind="SERVER", otel_span_status_code!="ERROR"}'
total:
metricSource:
type: Prometheus
spec:
query: '{otel_metric_name="dash0.spans", service_namespace="slo-coach", service_name="slo-coach", deployment_environment_name="production", otel_span_kind="SERVER"}'
objectives:
- displayName: 99.5% availability
target: 0.995Then open the Overview tab. You'll see your target, how much error budget is left, and how you're doing over the last 2 hours, 24 hours, 7 days and 28 days.
Good to know:
- Charts start empty. Dash0 starts measuring when you create the SLO and doesn't fill in the past. Give it a few minutes.
- The SLO is read-only in the UI because it was created from code. To change it, edit the YAML and send it again.
Step 4: Mark every deploy on the SLO
What you paste: prompt 4.
What the agent does: adds one step to your CI pipeline. Every time you deploy, it tells Dash0 "a new version just went out", whether the deploy worked or failed.
What you should see: a small rocket icon on the SLO's charts. Hover over it to see which version went out, where, and whether it succeeded.
If there's no rocket: the deploy event must use exactly the same service.name, service.namespace and dataset as the SLO. Check them letter by letter.
Step 5: Get alerted when the budget burns too fast
What you do: open your SLO and click Create check rule. Dash0 fills in the rule for you. Click Save.
That rule fires when you're burning budget too fast. If you want two levels, save the rule, clone it, and keep one signal in each copy:
| Signal | What it means | Send it to |
|---|---|---|
| Fast burn | Something you just shipped is hurting users right now | Paging |
| Slow burn | A small, quiet problem that will break your promise before the 28 days are up | Your ticket queue |
For the curious, the exact thresholds: fast burn fires at 13.44x normal over 1 hour (confirmed over 5 minutes) or 5.6x over 6 hours (confirmed over 30 minutes). Slow burn fires at 2.8x over 1 day (confirmed over 2 hours) or 1x over 3 days (confirmed over 6 hours).
How to read your SLO after a deploy
After your next deploy, open the SLO and look at the Burn rate chart next to the rocket icons.
- Flat line after the rocket: the deploy is fine.
- Line jumps up right after the rocket: that deploy is the first thing to check. Use More actions > View bad events in Traces to see the failing requests.
One SLO for several services
Some promises cover more than one service. For example, "checkout works" might depend on the frontend, the cart and the checkout service. You can put them all behind one SLO in the Dash0 UI:
- Open SLOs and create a new SLO.
- Pick Good / Total or Bad / Total.
- Set Service to No service. Do this first, or the next step won't show up.
- Under Event scope > Filters, add service.name and tick every service you want.
Adding a latency SLO
A latency SLO is a promise about speed, for example "99% of requests finish in under 300 ms". It uses the same YAML file with a different rule inside. The guide has a prompt that picks a sensible threshold from how fast your service is today.
Frequently asked questions
Which AI coding agents does this work with?
Claude Code, Cursor, Windsurf, Copilot CLI and similar agents. The prompts carry every rule the agent needs, so you don't install anything else.
Do I need an OpenTelemetry Collector?
No. Your app sends data straight to Dash0. If your Kubernetes cluster runs the Dash0 operator, it handles the address and the token for you.
Why does my new SLO show no data?
Dash0 starts measuring when you create the SLO, with a 5-minute delay, and doesn't fill in the past. If it's still empty after that, make sure your service is getting requests in the same dataset and environment as the SLO.
Why is there no deployment marker on my SLO?
The marker only shows up when the deploy event's service.name, service.namespace and dataset match the SLO exactly. In Dash0, open Logs, filter on otel.event.name = dash0.deployment, and compare the names letter by letter.
How many SLOs can I create?
25 SLOs per organization are included. Start with five, on the services your customers would notice first if they broke.
Build one with us
Open the five-prompt guide and point your agent at a service you own. Or join the hands-on SLO Workshop, From Zero to SLO in Five Prompts, on Thursday 5 November 2026 at 11:00 ET, and we'll do the five prompts together. Register link
Related docs: About SLOs, Create SLOs, Alert on SLOs, Manage SLOs as code.