What this prompt does
This prompt sets up comprehensive CloudWatch observability for an [application_type] running across [services_list]. It instruments [application_name] to publish [business_metrics] using the embedded metric format from [compute_service], builds operations dashboards with [dashboard_sections], and configures [alarm_count] alarms covering [alarm_scenarios]. The goal is to actually see what a system is doing before something breaks, rather than reconstructing it afterward from raw logs.
The structure works because it pairs signal with noise reduction. It defines composite alarms combining [composite_conditions] so on-call only pages when conditions like high error rate AND elevated latency coincide, writes saved Log Insights queries for [log_query_scenarios], enables anomaly detection on [anomaly_metrics], and even estimates CloudWatch cost against [monitoring_budget]. Business metrics plus composite alarms cut the alert fatigue that gets monitoring ignored, and the saved queries pay off the first time you debug an incident at speed.
When to use it
- You are standing up monitoring for a new
[application_type]and want it instrumented before launch - Your alerts are noisy and you need composite alarms to escalate only on meaningful
[composite_conditions] - You want business metrics like
[business_metrics], not just CPU and memory, on your dashboards - You need a library of saved Log Insights queries for
[log_query_scenarios]ready before the next incident - You want anomaly detection on
[anomaly_metrics]to catch drift that static thresholds miss - You need to keep CloudWatch spend under a
[monitoring_budget]with sampling and aggregation
Example output
Expect an observability plan: instrumentation guidance for publishing your business metrics via embedded metric format, dashboard definitions with appropriate widget types for each section, a set of alarms with evaluation periods and thresholds, composite-alarm definitions, saved Log Insights queries with regex and stats aggregation, anomaly-detection configuration, cross-account sharing setup, and a cost estimate with reduction strategies to stay under budget.
Pro tips
- List
[business_metrics]that map to outcomes you care about — orders per minute and payment success rate tell you more during an incident than raw infrastructure counters - Use
[composite_conditions]to combine signals before paging; requiring error rate AND latency together kills most false alarms from a single transient spike - Make
[log_query_scenarios]specific, like "error rate by endpoint" or "slow query identification," so the saved queries are ready to run mid-incident - Give anomaly detection on
[anomaly_metrics]a real training period before trusting its bands; it needs baseline data to avoid noisy alerts - Keep an eye on
[monitoring_budget]— high-cardinality custom metrics and verbose logs add up fast, so apply the sampling strategies the prompt suggests - The model proposes thresholds, but tune them against your real traffic; a latency threshold that fits one workload will flap on another
- Pick widget types in
[dashboard_sections]deliberately — gauges suit single health values, while line charts suit latency percentiles over time - Set up cross-account sharing from
[source_accounts]to a central monitoring account so on-call has one place to look during an incident instead of hopping between accounts
