Alerts

Monita alerting has two layers. Auto Alerts watch everything by default — every vendor-event signal in your traffic, from the moment it first appears. Custom Alerts are your own rules for specific escalations: exact thresholds, data validations, journeys, with your own channels and severity. Both file into Issues.

Auto Alerts

Three engines run continuously, configured under Alerts → Auto Alerts:

• Volume — seasonal anomaly detection on every signal. Choose the scan frequency (every 15 minutes up to daily) and an org-wide sensitivity: high (more alerts), balanced, or low (fewer alerts).
• Data — AI review of payload drift per vendor, on a 6-hour, daily or weekly cadence.
• Compliance — PII-shaped values in payloads and blocked vendors still firing.

The signal catalog below the engines lists every signal with its trend, model readiness and open issues. Per signal you can set monitoring to On, Muted (tracked, no issues) or Off, and override the sensitivity. Opening a signal shows its anomaly chart with the expected band, plus a backtest: what each sensitivity level would have flagged over recent weeks — click a level to preview its band on the chart before applying it.

Seasonality & calendar teaches the engine your planned exceptions: add windows that either suppress alerts (maintenance, migrations, code freezes) or declare elevated traffic (Black Friday, campaigns), optionally repeating annually. Set the org timezone here too — window dates are interpreted in it.

Notify me is personal: subscribe yourself to an email the moment an auto engine opens an issue, per pillar, and to a recurring briefing written for your role.

By default the engines watch production traffic only; a toggle extends the same monitoring to dev-script installs (expect more noise — staging traffic is bursty).

Custom alert types

Type	Fires when
Data validation	An event matches your conditions — the only type that can run realtime, evaluated the moment each event arrives.
Volume threshold	A full window’s count is at most / at least N. The honest replacement for “tag does not fire” — a whole window at ≤ N is real; a momentarily empty minute is not.
Volume change	The count moves by at least X% versus the prior period (hour-on-hour, day-on-day, and so on).
Volume anomaly	The ML seasonal engine flags one signal — same detection as Auto Alerts, but with your channels, severity and sensitivity.
Journey	Sessions on a path stop firing the tags the path requires — usually drafted from the Journeys page.

“Auto covers this”

A plain “count ≤ 0” threshold or a balanced-sensitivity anomaly rule duplicates what Auto Alerts already watch. The builder and the alert list flag these — keep the rule only if you need its specific channels or severity.

Building a rule

1. Define. Name the rule, pick the type and a severity (low → critical). Optionally attach a dollar impact — issues it raises carry that value.

2. Scope. Pick the properties (any subset, or all) and the vendor; leave the event blank to count everything the vendor sends.

3. Conditions. Data-validation rules are built from condition groups: each group matches ALL or ANY of its rows, and multiple groups are OR-ed together. Fields come from a catalog of what your traffic actually sends — envelope fields (event, vendor, URL, path, consent state, GTM tag name/status…) and every observed payload key per vendor, with presence and recency shown. Operators include equals/contains/starts-with families, blank checks, length and numeric comparisons, regex, and PII detectors (contains email, contains phone). Value fields suggest observed values, and pasting a comma-separated list splits into one chip per value. Volume rules accept an optional “only count events matching…” filter with the exact-match operator subset.

4. Period. Realtime (data validation only) or a comparison window from every 15 minutes to weekly — each scheduled check evaluates the window that just ended. Anomaly rules are pinned to hourly, the engine’s own grain. Scheduled rules can also be confined to a run window: specific local hours and days of the week, in the rule’s timezone.

5. Notify. Add destinations — see below. Realtime rules get a burst limit: at most N notifications per M minutes, while occurrences keep counting.

Preview and backtest

• Live preview (data validation): as you edit conditions, Monita evaluates the draft against a sample of your last 24 hours with the production engine — matched counts and expandable matching events, before you save.
• Backtest (any type): replay the draft against 7, 14 or 30 days of history and see exactly when it would have fired — before it pages anyone.

Destinations

Rules deliver to email (multiple recipients — one entry each on the issue timeline), Slack, Teams and webhooks; Jira files issues through its own auto-file rules. Connect Slack and Teams once under Integrations and they become one-click targets, with a per-rule override of the default channel. You’re notified when a rule opens an issue and again when it recovers — checking often never means paging often.

Manage rules

• Enable / disable with the switch on any row — disabled rules keep their configuration but stop evaluating.
• Bulk actions: select rows to enable, disable or delete together. Deletion is permanent.
• Export / import: download all rules as JSON and bulk-import the same shape — useful for promoting alert sets between organisations. The import dialog includes a ready-made prompt you can hand to any AI assistant; it embeds the format and your current rules so the assistant writes valid JSON in your house style. Or skip JSON entirely and manage alerts conversationally through the MCP server.