Set Up Metric Monitoring and Alerts

Full method. Works on any model.

You are a senior product analytics lead who has built metric monitoring and alerting systems for subscription and product led businesses. You design monitoring that is reliable, automated, and actionable, and you are ruthless about avoiding false alarms because every false alarm trains people to ignore the next real one.

I want a complete monitoring and alerting specification for my core metrics.

CONTEXT
→ Business model: {{BUSINESS_MODEL}}
→ Metrics to monitor (with current values or ranges if known): {{METRICS_LIST}}
→ Owner or team who can act on each metric, if known: {{OWNERS}}
→ Monitoring cadence available (real time, hourly, daily, weekly): {{CADENCE}}
→ Alerting channels available (email, Slack, PagerDuty, dashboard tool, etc.): {{ALERT_CHANNELS}}
→ Any metric that must never move (errors, crashes, downtime): {{HARD_STOP_METRICS}}

Before you build anything, if any of the following are missing or ambiguous, ask me up to five clarifying questions and stop: what the exact definition and data source of each metric is, whether historical values exist to compute a baseline, who owns each metric, what a truly urgent movement looks like versus normal noise, and how the metric currently gets reported. Never present an invented number as if it came from my data. When you must propose a threshold without historical values, label it PROVISIONAL and state the assumption it rests on.

METHOD
Work through every metric using these steps.

1. Establish the baseline. State the normal range for the metric using whatever anchor fits: a moving average (for example the previous 7, 30, or 60 days), a normal average, a median, or a budgeted target. If no history exists, say so and recommend collecting a baseline window before alerting. A baseline exists so you know when to sound the alarm and, just as important, when not to.

2. Classify the metric and pick a threshold type.
   → Fixed threshold for metrics that should never move (critical errors, app crashes, downtime). Set the threshold at the hard boundary, usually zero, and treat any breach as an alert.
   → Moving or variable threshold for volatile, externally influenced metrics (traffic, signups, conversion rate). Express it as a deviation rule, for example "must not exceed the maximum of the previous 60 days" or "must not move more than 10 percent versus the previous 7 days." Treat this like a service level target for that metric, the way an uptime SLA defines acceptable downtime.

3. Set the tolerance. Give the numeric trigger and the direction that matters (up, down, or both). Example: "churn must never exceed 1 percent, alert when it crosses." If I gave you no historical values for a metric, still propose a starting trigger, mark it PROVISIONAL, and say what would confirm or replace it. Make every threshold adjustable, because you will tune it: too tight produces false positives, too loose misses real events.

4. Assign severity. Label each alert critical, high, or informational, the same way bugs are triaged. Reserve critical for movements that trigger a chain of operational consequences.

5. Write the alert message. It must be precise and actionable, naming the metric, the size and direction of the movement, and the time window. Write "incoming trial volume decreased 60 percent since [date]," never "a metric has a problem."

6. Route the alert. Name who is notified, confirm they can act, and map each severity level to one of my alerting channels: critical alerts go to the channel that interrupts (pager, phone, a monitored real time channel), high goes to the team channel, informational goes to a digest or dashboard. Route by role: the metric owner is the primary responder, DevOps and developers are added for technical or instrumentation metrics, and management is added only for critical alerts with direct operational impact. At minimum loop in the operations lead when the impact is real.

7. Label leading versus lagging. Mark each metric as a leading indicator (signals change before impact, for example customer satisfaction, trial signups) or a lagging indicator (shows impact after it happened, for example revenue, churn), and state what it predicts or reflects, so responders know whether they are catching a cause or confirming an effect.

RULES AND CAUTIONS
→ Automation is non negotiable. A report that needs manual updating fails the moment its owner is on holiday. Flag any metric whose pipeline is not automated.
→ Reliability beats tooling. Which system you use matters far less than whether it runs and alerts every time. Unreliable alerting negates the whole system.
→ Keep the monitored set small and high level. Monitoring 80 to 100 metrics makes it impossible to derive and act on anything; a metric that only exists for vanity is not worth an alert.
→ Correlation is not causation. A movement is a trigger to investigate, not proof of cause. Frame alerts as the start of a "why" investigation.

OUTPUT FORMAT
First, a one line summary of the monitoring approach.
Then a table with one row per metric and these columns: Metric | Baseline anchor | Threshold type (fixed or moving) | Trigger and direction | Severity | Leading or lagging | Alert message template | Owner and channel.
Then a short "tuning and rollout" section: which thresholds to watch for false positives first, what baseline window to collect before alerts go live, and which teams to brief so they request their own alerts.
Finally, a "verify before wiring" list: every PROVISIONAL threshold with the assumption behind it, every metric definition or data source you assumed rather than confirmed, and every metric whose pipeline automation status is unconfirmed. These are the facts I must check before any alert goes live.

SELF CHECK before you finish
→ Verify: every threshold has a concrete number or a named deviation rule, not a vague word like "significant."
→ Verify: every number is either taken from my context or labeled PROVISIONAL; none look data derived when they are not.
→ Verify: every alert message names the metric, the movement, and the window.
→ Verify: each metric has a real owner who can act; flag any that do not.
→ Avoid: alerting on so many metrics that the team tunes them out.
→ Avoid: fixed thresholds on naturally volatile metrics (guaranteed false alarms) and moving thresholds on metrics that must never move.
→ Avoid: recommending a specific tool over reliability and automation.

For the most capable models. Goal and quality bar up front.

You are a senior product analytics lead who has built reliable, actionable metric monitoring for subscription and product led businesses.

Goal: turn my core metrics into a complete monitoring and alerting specification I can hand to whoever wires up the alerts. Open your reply with the one line monitoring approach and the metric table; put tuning notes and caveats after.

Context to work from:
→ Business model: {{BUSINESS_MODEL}}
→ Metrics to monitor, with any known values or ranges: {{METRICS_LIST}}
→ Owner or team who can act on each metric: {{OWNERS}}
→ Cadence available (real time, hourly, daily, weekly): {{CADENCE}}
→ Alerting channels available: {{ALERT_CHANNELS}}
→ Metrics that must never move (errors, crashes, downtime): {{HARD_STOP_METRICS}}

Principles that are non negotiable:
→ Give every metric a baseline anchor (moving average, median, or budget). If no history exists, say so and recommend a baseline window before alerting.
→ Type each threshold correctly: fixed at a hard boundary for never move metrics, moving deviation rules for volatile ones. Never fix a volatile metric or float a hard stop.
→ Make every threshold a concrete number or named deviation rule, adjustable, with the trigger direction stated.
→ Assign severity (critical, high, informational), map each level to a channel that fits its urgency, and name an owner who can act.
→ Write alert messages as sentences a busy person acts on immediately: metric, movement size and direction, time window.
→ Tag each metric leading or lagging and say what it predicts or reflects.
→ Treat any movement as a trigger to investigate, not proof of cause. Flag any metric whose pipeline is not automated.

Quality bar: the spec reads as ready to wire. Thresholds carry numbers or deviation rules, not adjectives. Severities route to channels that match urgency. Alert templates are specific enough to act on cold. The monitored set stays small and high level, and every provisional or assumed value is called out for me to confirm before alerts fire.

Boundaries: do not present an invented number as if it came from my data; label any threshold set without history PROVISIONAL with its assumption. Do not pad with generic monitoring advice or recommend a specific tool over reliability. If a metric definition, data source, or history is missing or ambiguous, ask up to five focused questions and stop rather than guessing.

Five lines. Speed over rigor.

Build me a metric monitoring and alerting spec for these metrics: {{METRICS_LIST}} (business: {{BUSINESS_MODEL}}, owners: {{OWNERS}}, channels: {{ALERT_CHANNELS}}).
For each metric give a baseline anchor, a threshold typed fixed or moving with a concrete trigger and direction, a severity mapped to a channel, an owner, and a one sentence alert template naming the metric, movement, and time window.
Never move metrics get a fixed threshold; volatile ones get a deviation rule. Label any number you did not get from me PROVISIONAL.
Quality bar: every threshold is a real number or deviation rule, never a vague word, and every alert message is specific enough to act on cold.