Alert Design: Fewer, Better Alerts

Redesign noisy alerts with a test of whether each one needs a human now, using your firing history and on-call setup.

Added October 15, 2026. Written with AI assistance and checked for clarity and placeholders; not reviewed by a lawyer, accountant, clinician or other professional. How these prompts are made

The Open buttons send the prompt text as currently shown below to that site only when you click. Fill in the placeholders first.

Redesign our alerts. Current alerts and how often they fire: [CURRENT_ALERTS]. Services and their importance: [SERVICES]. On-call setup: [ON_CALL_SETUP]. Pages that were ignored or false: [NOISY_ALERTS].

Use this test for each alert: does it need a human now, is it actionable, does it describe user impact, is there a runbook? Remove or downgrade those that fail. Define severity levels and the response for each. Propose alerts based on symptoms such as error rate and latency rather than causes such as CPU.

Return a table of alerts with keep, change or delete, new thresholds as proposals to test, runbook links as placeholders, and a monthly review that counts pages per week with a target. Show arithmetic for percent of pages that required action.

Add a worked example of an alert rewrite: instead of alerting when CPU exceeds 80 percent for one minute, alert when the share of failed requests exceeds 2 percent for five minutes, because that is what users feel. Add a rule that every alert has an owner and a runbook, and a monthly review of the five noisiest alerts. Include an example of calculating the share of pages that needed action: 18 actionable pages out of 60 is 30 percent, which is a sign that most pages are noise. Suggest a target such as 70 percent actionable after three months and a route for muting alerts temporarily with an expiry date.

Add a worked weekly count with invented numbers: 60 pages, of which 18 needed action, so 30 percent were useful. After removing eight noisy alerts and fixing three thresholds, the next week has 24 pages and 17 needed action, 71 percent. Describe a simple change process for alerts: propose, test in a quiet mode for a week, review the false alarms, then enable. Add an ownership rule so every alert has a named team, and an expiry date on temporary silences so they do not hide problems for months. Suggest recording each alert change in a log with the date and reason, so that later reviewers can see why thresholds were chosen.

Fill in before use

Optional: type your details and the prompt above updates. Nothing is saved or sent.

Replace each bracketed placeholder with your own details, then paste into Any AI or another assistant.

Invented week: 60 pages, 18 needed action = 18 / 60 = 30 percent useful.
Change: remove 8 noisy alerts; replace CPU above 80 percent with failed request share above 2 percent for 5 minutes.
Next week: 24 pages, 17 needed action = 17 / 24 = 71 percent.
Each remaining alert has an owner, a severity and a runbook link. Temporary silences expire in 7 days.
Review: the five noisiest alerts every month.
Ownership: platform team owns the failed-request alert; the runbook link is attached. Target: 70 percent of pages actionable within three months.

• monitoring