Anomaly alerts

Volume drops, no-activity, new-scenario, probe failures.

Anomaly alerts watch your monitored events for trouble. A nightly cron compares each scenario's last 24 hours against its 14-day baseline (excluding today, excluding the install-check ping) and raises an alert when something looks wrong. Alerts appear in-app immediately; email is opt-in.

What we look for

  • volume_drop — an event scenario fired today but at <50% of its 14-day average. Severity: warning.
  • volume_spike — >3× the baseline. Severity: info (useful, not alarming).
  • dod_spike — today > 5× yesterday. Severity: info.
  • no_activity — a scenario with established baseline fired 0 events today. Severity: warning. Most common reason: GTM published bad version or your CMS deploy broke a selector.
  • new_scenario — a scenario's first-ever events arrived today. Severity: info — useful for confirming a new install is live.
  • probe_failed — the active probe (a scheduled headless load that checks your Monitor tag + dataLayer are actually present) hit a hard failure on this domain 3 runs in a row. Severity: critical.
  • goal_achieved — a minimum goal hit its target this period. Severity: info (positive).

Alert lifecycle

  • Cron raises an alert. State: open.
  • You can Mute for 7 days (suppresses re-raises but keeps the row visible) or Resolve (closes it).
  • On the next cron run, if the condition no longer holds, the alert auto-resolves. (Exception: probe_failed is owned by the probe runner, not the anomaly sweep — it resolves when the probe passes.)
  • An open alert won't duplicate. The DB has a partial-unique constraint = 1 open alert per (org, domain, scenario, channel, type).

The Alerts log

/dashboard/alerts shows every alert with severity colour, plain-English description, the domain + scenario it applies to, and when it was raised. Filter by status or domain. The ProTabs counter reflects the count of open alerts so you see it from any dashboard page.

Email digest

Off by default — your channel preference starts at "in-app only" so the launch experience is quiet. To opt into emails, open /dashboard/account/notifications and switch your channel to "Email". While you're there:

  • Set quiet hours (e.g. 22:00 – 07:00 your timezone) — alerts raised in that window are deferred, not sent.
  • Mute specific domains so they never email you (still appear in-app).
  • Toggle which severities you want to be emailed for.

Digest emails are deduped — one per alert per 72h, even if the alert keeps re-raising.

Common questions

I just installed monitoring; why are there no alerts yet? The baseline needs ≥5 full days of counter history per signal before drops/spikes can fire. On a fresh install, you'll only see new_scenario alerts for the first week.

I muted an alert; will it ever fire again? After 7 days. Mute is short-term; for permanent suppression, Resolve it (it'll re-raise if the condition reappears).

Can I get alerts for one scenario but not another on the same domain? Not at scenario granularity yet — domain-mute is the finest knob today. Granular mute is on the roadmap.

💡 Email volume is conservative on purpose

Pro's default is in-app only because we don't want to be the tool that emails you in the middle of the night about a false positive. Turn email on once you trust the signal — most users do that within their first week.