Prometheus Alerting Rule Writer

What This Prompt Does

This prompt generates valid Prometheus YAML alerting rules. It defines alert names, thresholds, time durations, labels, and annotation templates to monitor systems like CPU spikes, network latencies, or database disk limits.

System Prompt

You are a monitoring specialist. Write a valid Prometheus alerting rule configuration.
Adhere to the Prometheus YAML schema:
1. Define the alert name clearly using CamelCase.
2. Formulate the PromQL expression using correct duration offsets.
3. Set the 'for' duration window to filter out transient spikes.
4. Include labels for severity level.
5. Populate annotation descriptions with dynamic parameter values.

User Prompt Template

Write a Prometheus alerting rule for the following scenario:
Metric query target: {METRIC_NAME}
(e.g., "node_cpu_seconds_total")

Alert trigger threshold: {THRESHOLD}
(e.g., "utilization > 90% for 5m")

Alert severity level: {SEVERITY}
(e.g., "critical", "warning")

Example Output

groups:
  - name: InfrastructureAlerts
    rules:
      - alert: HostCpuUtilizationHigh
        expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 90
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Host CPU utilization is high on {{ $labels.instance }}"

When to Use This

Use this prompt when defining new Prometheus alerting rules for a service you’re onboarding into monitoring, particularly when you know the metric you want to alert on but aren’t fluent in PromQL’s specific query syntax for expressing thresholds, rates, and time windows correctly.

Tips for Best Results

• Provide the actual metric name and its type (counter, gauge, histogram) rather than a general description, since PromQL syntax for rate-of-change alerts on counters differs meaningfully from simple threshold alerts on gauges.
• Specify a reasonable for duration (how long a condition must persist before firing) explicitly — alerts that fire on a single noisy data point rather than a sustained condition are one of the most common sources of alert fatigue in production monitoring.
• Validate generated alerting rules against Prometheus’s rule linter (promtool check rules) before deploying them, since subtle PromQL errors can result in an alert that silently never fires rather than producing an obvious error.

Reviewing existing alert rules for similar metrics elsewhere in your monitoring setup before generating a new one helps keep threshold conventions consistent across your alerting configuration as a whole.

Documenting the reasoning behind a chosen threshold directly in the alert’s annotations makes it much easier for whoever is paged months later to judge whether the alert is still calibrated correctly.

This small habit compounds significantly across a monitoring setup that accumulates dozens or hundreds of alerts over time.