What this prompt does
This prompt makes the AI a Site Reliability Engineer that designs a complete monitoring and alerting stack for a [app_type] on [infrastructure]. You provide the [services], the [traffic_volume], and the [sla_target], and it produces five parts: a metrics collection strategy, a Prometheus configuration, four Grafana dashboards, tiered alert rules, and on-call runbooks. The output is an observability blueprint built around the RED method (Rate, Errors, Duration) rather than a vague list of things to graph.
The structure works because it ties alerts to symptoms, not noise. The metrics layer spans infrastructure, application, business ([business_metrics]), and database signals. The alert rules are tiered P1 through P4 with response times and channels, and they explicitly avoid false positives by using multi-window burn-rate rules and requiring sustained conditions instead of single spikes. Every P1 and P2 alert gets a runbook with the first three diagnostic commands and common fixes, plus whatever you add in [additional_concern], so on-call stays sane.
When to use it
- You are standing up observability for a multi-service app and need a coherent plan
- Your current alerts are noisy and you want symptom-based, burn-rate alerting instead
- You need Prometheus scrape configs and recording rules sized to your traffic
- You want four purpose-built Grafana dashboards, not one cluttered catch-all
- You need an SLA-aligned alert tiering with the right channels per severity
- You want runbooks so a paged engineer knows the first commands to run
Example output
You get a metrics catalog organized by layer, Prometheus scrape and recording-rule configs with retention sized to [traffic_volume], four Grafana dashboard specs (Overview, Service Detail, Infrastructure, Business) with panels and queries, a tiered P1-P4 alert table with conditions and channels, and per-alert runbooks listing the first diagnostic commands and common root causes.
Pro tips
- List every service in
[services]precisely so each gets its own scrape config and dashboard panels - Set
[traffic_volume]realistically; retention and storage sizing depend directly on it - Make
[sla_target]exact (99.95% with the minutes/month) so burn-rate alert math is meaningful - Use
[business_metrics]to surface revenue-impacting signals, not just infrastructure health - Add the easily-forgotten check via
[additional_concern], like SSL certificate expiry alerts - Treat the alert thresholds as starting points and tune them against real traffic to kill remaining false positives
