Alerting

The Alerting screen answers a question most security products cannot: "Who gets told about what, how fast, from which mailbox - and what did you actually send us last week?" Detection, alerting and notification are three different things here, and this is where the last two are configured and audited.

What You Can Achieve

Three Layers, Not One Switch

• Detection always runs. Policies count, detectors baseline, episodes are recorded - turning alerting down never loses history.
• Alerting decides whether an episode deserves attention: the alert line for anomalies, the instant trigger or digest cadence for policies, the per-entity overrides.
• Notification decides who is told, when, from where - recipients, cooldowns, timezone-anchored digests, the sender mailbox.

Every control on this screen changes one of the last two layers and says so. Detection is never the thing you are turning off.

Alert Rules

One row per origin, each with the same leading glyph the rest of the app uses for that screen. Source tells you where it comes from - trend, activity, anomaly detector or automation. Alerting shows every channel the rule has, side by side, so "instant and a weekly digest" reads as two chips, not one label: ⚡ instant (mailed the moment a line is crossed - hover for the trigger), 🔔 digest (a reporting cadence - hourly to weekly, weekly anchored to a day and hour in your company timezone), or No alerts · detection runs - which is a state, not a failure: the rule keeps counting and keeps its trend line, it just doesn't email anyone yet. A digest chip turns grey with a warning when the rule has nobody to mail - the cadence runs, every run is withheld. Anomaly detectors read the tenant anomaly rule for their instant/digest chips and add muted for N entities / tuned for N entities from their own overrides; policy rules add N watched when entities are on heightened watch, because those mail instantly on any rule they newly match.

Hits now is the number to read before deciding whether a rule deserves a channel at all: the rule's current matches, counted lazily as rows scroll into view - now (evaluated live against current data, 1000+ when capped), open episodes (an anomaly detector's alerted-tier episodes, the same figure the Anomalies screen shows) or last evaluation when a live count is not possible for that rule shape. One query (getAlertFindingsCount) answers it for every source.

The Notify bell switches a rule's notifications off (and back on) in one click without opening it; select rows to do it in bulk - Notifications off, Digest on, Instant on. Switching notifications off never stops detection: the cadence keeps evaluating and the trend line keeps drawing, only the mail stops. The quick-filter chips above the table - Instant, Digest, Instant + digest, No alerts · detection only, Nobody to mail, With overrides, sources - carry live counts and filter the list like every other screen; All filters opens the full drawer.

Recipients are the explicit addresses on the rule; when none are set, the policy owners and default user are used. The instant channel additionally falls back to the tenant's administrators; a digest does not - a digest rule with nobody to mail shows Nobody with a warning and is counted under No recipients above, so it is never silently un-notified. Actions and Grace period show what an automation will do and how long it waits for review. Last sent and Last withheld come straight from the notification log.

Click a policy row to open the same alert-rule editor the Trends, Activities and Automations screens use. Its instant trigger When it departs from its own history is the anomaly detector applied to the rule's own match-count series: spikes are scored exactly like the Anomalies screen, at the alert line set by Alert sensitivity there - one sensitivity, read in both dialogs; drops are a plain percentage below the trailing median, because the scoring engine is spikes-only by design. When the match count passes a number is the fixed threshold. Two severities live there, because they are two different statements about the same policy: Severity when it reports is what the digest carries; Page as is what the instant channel carries when the line is crossed. A trend that reports weekly at info can page at high - the cyclic report is background, the spike is not.

The Notifications Tab - a Log of Decisions

Every notification producer writes here at the moment it decides, whether or not a mail went out - the tab lists withheld and failed decisions next to the sent ones, which is why it is not called "Sent". A row is one of three outcomes:

• Sent - who received it, which sender was used (your own mailbox or the platform mailer), the subject and the effective severity.
• Withheld - and the exact reason: muted by an override, info tier while the rule notifies on alerted only, inside the cooldown window, not a record against its own baseline (repeat), nothing to report, no recipients, no mail sender configured, and a few more. Suppressions are recorded once per episode and reason, so a re-evaluated episode does not flood the list.
• Failed - the mail provider refused the send; the error is on the row.

Click any row to open it: the header carries the outcome, channel and when; the overview explains a withheld row in plain words and what would fix it (with a shortcut into the rule's alert editor), lists the recipients and sender, and links the rule and the subject entity. The second tab holds the actual items behind the notification - for a digest, that scan's users, files, sites or apps as the same interactive lists the rest of the app uses; for an anomaly notification, the episodes raised on the entity.

The quick-filter chips above the table carry the counts - outcome, channel, source, reason - and the All filters drawer holds the full set including a date range; the same filter bar the rest of the app uses. Times render in the company timezone. The same rows are available on each user, application and agent drawer under Notifications, and to your SIEM through GET /api/v1/notifications with the notifications:read scope.

Overrides - From Tenant Posture Down to One Entity

The tenant anomaly rule (in the header) is the top of a hierarchy. Below it, an override is a partial rule scoped to:

• one anomaly type - a detector such as Abnormal file downloads per user, for every entity;
• one resource - a single user, application, AI agent, device, site or group, across all detectors or narrowed to one;
• the members of a group (cohort) - a leaving team, contractors, a high-risk department - resolved against live membership every time it is applied, so joiners and leavers are covered without editing the override.

Only the fields you set win; everything else inherits. You can move the alert line for that scope (the same slider and vocabulary as the Anomalies screen), mute notifications, or change whether the info tier notifies. Every override carries a reason and, by default, an expiry of 7, 30 or 90 days. Permanent is offered and deliberately discouraged.

The canonical case: an employee has resigned. Open their drawer, click Tune alerting, pick the Heightened watch preset - the line drops one notch, info-tier episodes notify too, and every policy is watched: the moment that person newly matches any trend, activity or automation policy (an external share, a download spike, a new admin role), one mail goes out, at most once per policy per day. It expires after 30 days on its own. The drawer shows a Watched chip for as long as it lasts, and the Users list can apply the same watch to a whole selection at once. Overrides are enforced at detection time, at read time in the queue, on the instant channel and in the digest, so the screen, the queue and the mail can never disagree.

Severity You Can Explain

The severity on a notification is not a label someone typed once. It is computed, and the reasons ride along in the mail and in the notification log:

1. Typed - the detector's or policy's own severity (info, low, medium, high, critical).
2. Tier - an anomaly episode below your alert line is info tier: stored for context, never mailed above low, whatever the detector says.
3. Graph context - what 1Security already knows about the subject lifts an alerted episode: a privileged account, a guest identity, reach into files with sensitive information, content exposed through anonymous links, sign-in without MFA; for applications and AI agents, tenant-wide file access, admin consent for all users, an unverified publisher, very broad agent reach. One reason lifts a tier; a toxic combination - privilege or tenant-wide access and sensitive reach - lifts two, capped at critical.

The same download spike on an ordinary user and on an admin who can reach labelled content are not the same event, and the mail says so: high because: detector high · alerted tier · privileged account · reaches files with sensitive information.

Deliverability - Mail From Your Own Domain

Alerts sent from a vendor's tenant look, to an enterprise anti-phishing stack, exactly like the thing it exists to quarantine. The Deliverability card walks through the fix in three steps, in any order: consent the 1Security Alerts app into your tenant (it holds Mail.Send and nothing else), enter the sender mailbox (your address, or a shared one such as security-alerts@company.com), then send a test alert and confirm - by hand - that it reached the inbox. Only that confirmation marks delivery verified; a provider accepting the message proves nothing about the quarantine folder. If the tenant path ever fails, mail falls back to the platform mailer and the fallback itself is recorded, because silently regressing to cross-tenant mail is exactly the problem this exists to fix.

Delivery Controls - Quiet Hours, Reply-To, Recipient Groups

• Quiet hours hold scheduled digests due inside the windows you define (wall-clock in your timezone, e.g. 22:00-07:00 on weekdays) and send them the moment the window ends - never dropped, and visible on the Sent tab as held by quiet hours until they go. Instant alerts are never held: the instant channel exists to interrupt, so anything on it goes out the moment it is detected, at any hour.
• Reply-To on mail sent from your own mailbox, so replies land where someone reads them; the mailbox also keeps a copy in Sent Items.
• Recipients are not only addresses: add Tenant admins, Policy owners or Members of a group to any recipient list. They are resolved when the mail is sent, so joiners and leavers are covered without editing rules.
• Per-detector cooldown: an anomaly detector that fires repeatedly waits out its own cooldown without silencing the other detectors.

Timezones and Digests

Weekly digests anchor to a day and hour - Monday 08:00 by default - in the schedule's timezone, then the company timezone you set in the header, then UTC. Daylight-saving transitions are handled by the zone name, never a fixed offset. A worker asleep at the send moment catches up on its next tick without double-sending. Your own timezone is detected on first visit and stored for later per-person rendering.

API

GET /api/v1/notifications (scope notifications:read) returns the notification log with the same fields the Sent tab shows - filter by source, kind, decision, reason, policyId, resourceType, resourceId, from, to. See the SIEM integration guide.