Dashboards are a pull model — someone has to remember to open one and notice something's wrong. Alerting flips that: the system pushes a notification the moment a metric crosses a threshold that matters, without requiring anyone to be actively watching. For time-sensitive marketing operations — paid media budget pacing, conversion rate drops, lead volume anomalies — the gap between an issue occurring and a human noticing it in a dashboard can be the difference between a minor correction and a week of wasted spend.

Threshold alerts vs. anomaly detection

The simplest and most common alert type is a static threshold: notify if daily spend exceeds $X, if conversion rate drops below Y%, if form submissions fall to zero for Z hours. These are easy to build and easy to reason about, but they're blunt — a threshold tuned for a normal Tuesday fires constantly on Black Friday, or misses a real 20% dip that happens to stay above the static floor. Anomaly detection compares current values against a rolling historical baseline (e.g. a z-score or percentage deviation from the trailing 7-day or 28-day average, accounting for day-of-week seasonality) and fires when the deviation itself is statistically unusual, regardless of absolute level. Most mature alerting setups use static thresholds for hard business-critical floors (spend caps, zero-conversion situations) and anomaly detection for everything where "normal" varies by day and season.

Alert type trade-offs

Type	Best for	Failure mode
Static threshold	Hard business limits (budget caps, zero-volume failures)	Either too sensitive on high-variance days or too insensitive on low-variance ones
Rolling baseline / anomaly detection	Metrics with natural day-of-week or seasonal variation	Needs enough historical data to establish a reliable baseline; noisy with sparse data
Rate-of-change alert	Catching fast-moving problems (sudden tracking breakage, pixel failure)	Can mask slow-burn degradation that never triggers a sharp rate-of-change event

conversion_drop_alert.ts

typescript

// Rolling-baseline anomaly check, run on a schedule (e.g. hourly via Cloud Function/Lambda).
async function checkConversionRateAnomaly() {
  const today = await getConversionRate("today");
  const baseline = await getTrailingAverage("conversion_rate", { days: 28, sameDayOfWeek: true });

  const percentDeviation = ((today - baseline) / baseline) * 100;

  if (percentDeviation < -25) {
    await sendSlackAlert({
      channel: "#paid-media-alerts",
      text: `Conversion rate is ${percentDeviation.toFixed(1)}% below the 28-day same-day-of-week baseline (today: ${today.toFixed(2)}%, baseline: ${baseline.toFixed(2)}%). Check tracking and landing pages.`,
    });
  }
}

Alert fatigue kills the whole system, not just the noisy alert

Once a Slack channel full of marketing alerts trains a team to ignore it — because thresholds were set too tight and it fires constantly on noise — people stop checking it even when a genuinely critical alert fires. Alert fatigue doesn't degrade gracefully; it's closer to a binary failure where the entire channel becomes background noise. Tune thresholds conservatively, route by severity to separate channels (critical vs. informational), and periodically audit which alerts actually led to action versus which were ignored.

Routing: who gets which alert, and where

Not every alert belongs in the same channel or medium. A budget-pacing alert that needs action within the hour belongs in a dedicated, actively-monitored Slack channel, possibly with a PagerDuty-style escalation if unacknowledged. A weekly summary of metric trends that's informational, not urgent, is better suited to a scheduled email digest that doesn't compete for real-time attention. Routing by severity and urgency — not just by metric type — is what keeps high-signal channels high-signal.

A minimal, durable alerting stack

Most teams don't need a dedicated observability platform to get real value here: a scheduled Cloud Function or Airflow task querying the warehouse, comparing against a stored baseline table, and posting to a Slack webhook on breach covers the majority of real-world marketing alerting needs. The complexity worth investing in is less about the alerting tool itself and more about getting the baseline/anomaly logic right and keeping thresholds maintained as the business changes — a threshold set correctly at launch and never revisited is a slow-motion alert-fatigue problem waiting to happen.

What's Next?

Getting the right number to the right person at the right time through alerting solves urgency — but the broader discipline of making data persuasive and actionable once someone is actually looking at it, rather than just accurate, is its own skill worth developing.

I build these systems professionally.

Whether it's a RAG pipeline, analytics migration, or AI workflow — let's talk.

Work With Me →

Need production AI or MarTech expertise? I build custom LLM workflows, server-side GTM tagging, and analytics infrastructures professionally.

Need custom AI or MarTech setup? Let's build together.

Let's talk →