SLO Burn-Rate Alert Tuning Prompt

You are an SRE designing SLO burn-rate alerting for a service. The goal is alerts that page early on genuine fast-burns of the error budget and stay silent on slow, tolerable noise — so on-call trusts the page and time-to-detect drops.

Give me:
- The SLO: [TARGET, e.g. 99.9% availability over 30 days; or latency SLO with threshold]
- The SLI definition: [WHAT COUNTS AS A GOOD vs BAD EVENT, AND THE QUERY IF YOU HAVE IT]
- Traffic profile: [REQUESTS/SEC RANGE, DIURNAL PATTERN, LOW-TRAFFIC PERIODS]
- Current alerting pain: [TOO NOISY / TOO SLOW / BOTH / NONE YET]
- Alerting stack: [PROMETHEUS/ALERTMANAGER, DATADOG, ETC.]

Work through this:

1. **Restate the error budget in concrete terms.** Convert the SLO into an absolute budget (e.g. "43.2 minutes of downtime per 30 days") so every burn-rate number below is grounded in something real.

2. **Propose a multi-window, multi-burn-rate scheme.** Recommend a small set of alerts — typically a fast-burn (short window, high burn rate → page) and a slow-burn (long window, lower burn rate → ticket). For each, give the burn-rate multiplier, the long and short windows, the budget-consumed threshold, and whether it pages or files a ticket.

3. **Justify each threshold against detection speed vs noise.** For each alert, state how quickly it would fire on a total outage, and what steady-state error level it would tolerate without firing. Call out the trade-off explicitly.

4. **Stress-test against low traffic.** Identify where sparse traffic would make the ratio jitter and cause false pages, and add a minimum-events guard or absolute-count floor to prevent it.

5. **Emit the rules.** Provide the alert definitions in the target stack's syntax, clearly labeled as a draft to be reviewed against the live metric names.

Output format: an "ALERT DESIGN" section (error budget in plain terms, then a table of alerts with WINDOWS, BURN RATE, THRESHOLD, PAGE/TICKET, TIME-TO-FIRE-ON-OUTAGE, TOLERATED-STEADY-ERROR), followed by draft rule definitions and a short list of assumptions I must verify. Flag any threshold you are unsure about rather than presenting all of them as equally validated.