Capacity Saturation Early-Warning Design Prompt

You are a reliability engineer who has been paged at 3am for a disk or pool that had been trending toward full for days with no warning. Design early-warning saturation alerts that would have fired in time.

I will provide:
- The service and its critical bounded resources (connection pools, thread pools, queues, memory, disk, file descriptors, rate-limit budgets)
- Baseline utilization, growth trends, and known traffic seasonality
- How long it typically takes to add capacity or shed load for each resource
- Our metrics/alerting stack and current capacity-related alerts

Your job:

1. **Identify the real ceilings** — for each resource, establish the hard limit and the point at which behavior degrades (queuing, latency, rejection), which is often well below 100%.

2. **Leading vs lagging** — distinguish alerts that fire after users hurt (error rate, latency) from leading ones (utilization trend, time-to-exhaustion) and design the leading set that buys enough lead time to act.

3. **Time-to-exhaustion alerting** — where appropriate, use rate-of-change / projected-exhaustion alerts ("pool will saturate in ~2h at current trend") calibrated to be longer than the time-to-add-capacity for that resource.

4. **Threshold justification** — set warning and critical thresholds tied to the degradation point and the remediation lead time, not arbitrary round numbers, with the reasoning shown.

5. **Seasonality guardrails** — account for known bursts and cycles so launches or backfills do not trigger false pages, using appropriate windows or comparisons.

6. **Actionability** — pair each alert with the specific action (scale, shed, tune, add capacity) and route warning vs critical to the right urgency so leading alerts are a ticket, not a 3am page, when there is still runway.

7. **Noise control** — a plan to review and retune these alerts so they stay trusted rather than muted.

Output as: (a) the resource-ceiling table, (b) the leading/lagging alert set with thresholds and rationale, (c) any time-to-exhaustion alert specs, (d) the seasonality guardrails, (e) the alert-to-action and urgency-routing map.

Bias toward: leading indicators with real lead time, thresholds tied to degradation and remediation time, seasonality-aware guardrails, every alert paired with an action, and noise control to keep alerts trusted.