# Examples — Alert Noise Reduction Agent

## Chronic non-actionable alert → time-boxed auto-suppress + tuning PR

An alert fires constantly, is never acked, and has never been tied to an incident, on a non-critical service. Safe, bounded noise to quiet.

**Input**

```
Alert: 'batch-worker-cpu-high' fired 312 times in 30d, ack rate 0.6%, 0 incident correlations, service=batch-worker (non-critical).
```

**Output**

```
{
  "alert": "batch-worker-cpu-high",
  "actionability": "Very low: 312 fires/30d, 0.6% ack rate, 0 incident correlations",
  "incident_linked": false,
  "critical_service": false,
  "decision": "AUTO_SUPPRESS",
  "suppression": { "applied": true, "duration": "24h", "scope": "batch-worker-cpu-high only", "reversible": true },
  "tuning": ["Raise CPU threshold from 80% to 92% for batch-worker, or add a 15m sustained-duration condition", "Group with batch-worker-memory into one 'batch-worker saturation' alert"],
  "rationale": "Fires constantly, almost never acked, and has never correlated with an incident on a non-critical service — textbook noise. Suppressing for 24h while a tuning PR adjusts the threshold; suppression auto-expires and is reversible.",
  "escalation": { "needed": false, "reason": "" }
}
```

**Note:** Clear, quantified non-actionability (312 fires, 0.6% acks, 0 incidents) on a non-critical service. It applies a bounded 24h suppression (auto-expiring, reversible) and — crucially — also opens a tuning PR so the real fix lands, rather than just muting forever.

## Noisy but incident-linked once → recommend tuning, do NOT suppress

An alert is genuinely noisy, but it correlated with a real outage once. The absolute rule blocks suppression; it recommends tuning instead.

**Input**

```
Alert: 'api-latency-p99-high' fired 140 times in 30d, ack rate 8%, but correlated with 1 real SEV2 incident last month. Service=api (customer-facing).
```

**Output**

```
{
  "alert": "api-latency-p99-high",
  "actionability": "Mixed: 140 fires/30d, 8% ack rate, but 1 real SEV2 incident correlation",
  "incident_linked": true,
  "critical_service": true,
  "decision": "RECOMMEND_TUNING",
  "suppression": { "applied": false, "duration": "", "scope": "api-latency-p99-high", "reversible": true },
  "tuning": ["Add a sustained-duration condition (p99 high for >5m) to cut transient spikes", "Raise the page threshold but keep a ticket-level alert", "Group flapping instances to reduce repeat pages"],
  "rationale": "It is noisy, but it correlated with a real SEV2 once and sits on a customer-facing service — so it must not be suppressed. Instead, recommend tuning to cut transient noise while preserving the signal that caught the incident.",
  "escalation": { "needed": false, "reason": "" }
}
```

**Note:** The defining rule in action: the alert is noisy enough that muting it would be tempting — but it caught a real SEV2 once, so the incident-linked rule forbids suppression entirely. The agent instead recommends duration/threshold tuning that reduces noise while keeping the signal that matters. Noise reduction never trumps catching incidents.

## Critical-service alert, noisy → escalate, never auto-act

A flapping alert on the payments service. Even with no incident link yet, the critical-service rule means a human decides.

**Input**

```
Alert: 'payments-error-rate' flapping, 90 fires in 30d, ack rate 30%, 0 incident correlations so far. Service=payments (critical).
```

**Output**

```
{
  "alert": "payments-error-rate",
  "actionability": "Moderate: 90 fires/30d, 30% ack rate, 0 incident correlations so far",
  "incident_linked": false,
  "critical_service": true,
  "decision": "ESCALATE",
  "suppression": { "applied": false, "duration": "", "scope": "payments-error-rate", "reversible": true },
  "tuning": ["Consider grouping by error type", "Possibly raise threshold — but only with payments-team sign-off given the criticality"],
  "rationale": "Even though it hasn't correlated with an incident yet and is somewhat acked, this is the payments service. I won't auto-suppress or auto-tune a critical-service alert; the cost of missing a payments issue is too high. Escalating to on-call with tuning options.",
  "escalation": { "needed": true, "reason": "Critical-service (payments) alert — tuning/suppression decisions require human sign-off regardless of current noise level." }
}
```

**Note:** Critical-service guardrail: payments alerts are recommendation-only, so even a plausibly-noisy one is escalated rather than touched. The agent offers tuning options but explicitly defers the decision to the payments team, because the downside of muting a real payments alert dwarfs the annoyance of noise.
