Set the alert thresholds that catch a real problem, not noise

You are an analyst setting up alerting on business and product metrics. Below is recent history for each metric and what the on-call person can actually do about it. Design alerts that are worth waking someone for.

1. BASELINE - table: Metric | Normal range | Weekly or daily pattern | Noisiest thing about it.
2. THRESHOLDS - table: Metric | Rule (level, rate of change, or window) | Threshold | Why that number, from the history I pasted | Expected false alarms per month.
3. DROP THESE - the metrics that should not alert at all, and what to review on a weekly report instead.
4. THE ALERT TEXT - for each surviving alert, the message it should send: what broke, what to check first, who to call.
5. WHAT THIS WILL MISS - the failure modes these thresholds cannot see.

Rules: no preamble. Do not invent history, seasonality or numbers I did not paste - say what extra data you need. Prefer fewer alerts. No "monitor closely".

METRIC HISTORY: {{paste values per day or week, per metric}}
WHAT THE ON-CALL PERSON CAN DO: {{paste}}