Alerts

Get notified when runs match the conditions you care about — by email, or delivered as JSON to your SIEM or webhook.

Alerts are scheduled rules that watch your account's completed runs and deliver the matches. Instead of checking the Monitoring Hub to see whether anything went wrong, define what "wrong" means once and let the platform tell you. Manage alerts from the Alerts view in the Monitoring Hub (the same dropdown that switches to Monitors). Alerts are account-scoped and managed by admins.

How a rule works

Each rule combines three things:

1. A filter over completed runs — all conditions are AND-ed, and any you leave empty means "any":

   • Failed-checks threshold — match runs with at least N failed checks.
   • Determinations — match explicit verdicts: Malicious, Suspicious, Clean, or the posture verdicts Critical, At Risk, Healthy (used by device and AI exposure runs).
   • Run types — restrict to URL, email, file, device, or AI exposure runs. An AI exposure rule on Critical or At Risk fires when a newly appearing AI tool or unverified app with data access is found by the daily scan.
   • Leaving everything empty matches every completed run (a send-everything digest).
2. A delivery channel — email or HTTP (see below).
3. A timing mode — immediate, hourly, or daily. This is the most important choice, because the two styles behave differently:

Immediate vs. batched

A rule has exactly one timing mode. Want instant notification and a guaranteed digest? Create two rules with the same filters — that's also the recommended safety net for immediate rules, since their delivery is best-effort.

A new rule starts watching from the moment it's created; there is no historical backfill.

Email alerts

Set the target to any recipient address — it doesn't have to be an account member. Alerts arrive from [email protected] and summarize each matched run: type, determination, failed/total checks, target, time, and run id. One recipient per rule (create additional rules for additional recipients).

HTTP alerts (webhooks, Splunk HEC)

Set the target to an https URL and the platform POSTs a JSON body per window:

{
  "rule_id": "…", "rule_name": "…", "account_id": "…", "schedule": "hourly",
  "window": { "since": "…", "until": "…" },
  "match_count": 12,
  "runs": [
    { "id": "…", "run_type": "URLDETONATOR", "determination": "malicious",
      "number_failed_checks": 4, "total_checks": 12, "target": "…",
      "submitter": "…", "run_end": "…" }
  ]
}

• Custom headers let you authenticate to the destination (API tokens, HEC tokens). Header values are write-only: the API never echoes them back, and editing a rule's headers replaces the whole set.
• The URL must be https, and private or internal addresses are refused.
• The runs array carries per-run summaries; fetch a run's full report by its id if you need the details.

Testing a rule

Every rule has a Test action (in the table, and as "Create & Send Test" / "Save & Send Test" in the rule form). It pushes a synthetic test alert — clearly marked [TEST] — through the rule's real channel, target, and headers immediately, so you can confirm your recipient, webhook URL, or HEC token works without waiting for the schedule. A failed test reports the delivery failure reason. Tests never affect the rule's real evaluation window.

Limits worth knowing

• A single digest (hourly/daily) lists up to 100 runs and covers up to 500 matches per window. If a window exceeds these caps, the alert says so — use the Monitoring Hub for the complete set. Tighter filters keep digests well under the caps. Immediate alerts carry exactly one run each, so the caps don't apply to them.
• Rules can be paused (toggled off) without being deleted, and resumed anytime.