Define SLOs and alerts that only page for real problems
Sets service level objectives and turns them into alert rules that catch user-facing problems without waking people up for noise.
The prompt
Help me define SLOs and alerting for a service.
Service and its users: [WHAT IT DOES, WHO DEPENDS ON IT]
Critical user journeys: [e.g. "log in", "load dashboard", "submit payment"]
Current alerts: [PASTE OR LIST - and which ones are noisy]
Historical performance: [AVAILABILITY, LATENCY PERCENTILES - or "unknown"]
Monitoring tool: [e.g. "Prometheus", "Datadog", "Grafana Cloud"]
On-call setup: [WHO GETS PAGED, TEAM SIZE]
Steps:
1. For each critical journey, define an SLI (what we measure, at which point, good vs. bad event) and propose an SLO target and window (e.g. 99.9% over 28 days). Explain the trade-off of the target; don't default to "five nines". If I gave no historical data, mark targets [VALIDATE against 2-4 weeks of data].
2. Calculate the error budget in plain terms (e.g. minutes of downtime or number of failed requests per window).
3. Design burn-rate alerts: a fast-burn alert that pages and a slow-burn alert that creates a ticket, with the windows and thresholds explained.
4. Review my current alerts: keep, convert to a ticket, convert to a dashboard, or delete. Every page should be urgent, actionable, and user-facing.
5. Suggest an error budget policy: what the team does when the budget is spent.
Return: an SLO table (journey, SLI, target, window, budget), the alert rules in my tool's syntax where possible, the alert review table, and a one-paragraph explanation for product stakeholders.
Highlighted [brackets] are blanks to replace with your own details.
Fill in the blanks and use this promptMore Software Development prompts
What to fill in
- WHAT IT DOES, WHO DEPENDS ON IT
- e.g. "log in", "load dashboard", "submit payment"
- PASTE OR LIST - and which ones are noisy
- AVAILABILITY, LATENCY PERCENTILES - or "unknown"
- e.g. "Prometheus", "Datadog", "Grafana Cloud"
- WHO GETS PAGED, TEAM SIZE
- VALIDATE against 2-4 weeks of data
How this prompt is built
This prompt follows the Few-Shot structure (Few-shot prompting). A few-shot prompt includes one or more worked examples of the input and the output you want, so the model can copy the pattern instead of guessing it.
Related prompts
- Analyze logs to find what went wrongReads logs to identify errors, patterns, and the likely root cause.
- Generate realistic test or mock dataRealistic synthetic datasets in CSV, JSON, or SQL for testing and demos.
- Break my first coding project into small buildable stepsA milestone plan where every step leaves you with a working program and tells you what to learn next.
- Get unstuck on a coding error with hints instead of the answerA plain-English explanation of your error and step-by-step hints, so you learn to debug instead of copying a fix.