Scheduled detection rules and templates

Every rule described in The detection library is a stream rule: always-on, evaluating events as they arrive. This article covers a second rule shape that now exists alongside it — a scheduled rule, which wakes up on a cadence, pulls a window of recent events, and runs the same detection logic over them in a batch.

A scheduled rule is not a rewrite of the detection engine. It wraps the same Sigma-shaped rule definition — selections, condition expression, threshold, group-by, MITRE mapping — and adds only scheduling metadata on top: mode, cadence, lookback, and a suppression window that spans separate runs rather than one continuous stream. A Sigma import becomes a scheduled rule by adding that metadata, not by re-parsing its logic, so the rule you get behaves exactly like the one you imported.

Threshold mode and absence mode

Threshold mode

Fires when a condition is met a stated number of times within a window, grouped by a field — the same aggregation shape the stream engine already uses, run in a batch instead of continuously.

Absence mode

Fires when a watched entity does NOT report within the window — the inverse of threshold mode, and something the stream engine cannot express at all, since it can only react to events that arrive, never to silence.

Cadence, lookback and suppression

Three settings control how a scheduled rule runs, distinct from the threshold/window/cooldown settings on the underlying detection logic itself (those are covered in Tuning a detection rule):

Cadence

How often the rule wakes up and runs at all.

Lookback

How far back each run's query window reaches — this is the span pulled from stored events on each run, capped at 50,000 rows.

Suppression window

Unlike a stream rule's cooldown, which quiets one continuous evaluation, this spans separate scheduled runs — so a condition that keeps being true does not reopen a fresh finding every time the rule ticks.

Overriding cadence with a cron expression

A rule's wake-up trigger can also be set as a standard five-field cron expression instead of the fixed cadence duration above, validated on save before it is stored. SIEM → Scheduled rules → Your rules has an Edit schedule action on every row that opens a modal with a single cron-expression input. Save a value and the rule wakes on that cron schedule from then on; clear the field back to blank and the rule falls back to its existing cadence duration exactly as before — this is a pure addition, not a replacement, and a rule you never touch keeps running on cadence unchanged.

A cron expression only replaces the wake-up trigger. Lookback and the suppression window are unaffected and still set the way they always were — a cron-scheduled rule still pulls the same lookback window and still suppresses repeat findings across runs the same way a cadence-scheduled one does.

The template gallery: 104 templates

A template is a thin scheduling wrapper — a stable pointer to one of the shipped stream rules, plus a set of category-tuned defaults for cadence, lookback and suppression. It is not a copy of that rule's title, MITRE mapping, severity or selections. At enable time, the underlying detection is resolved fresh from the live rule catalogue, which has a consequence worth understanding: if we later correct a shipped rule's logic, every tenant who enabled a template built on it inherits that correction automatically, without the template itself changing and without you doing anything.

104 is every rule in the 105-rule shipped stream library except one — the collector silent-source health rule, which alerts on the health of the collector layer itself rather than on tenant telemetry, and would duplicate an existing six-hour health job if it were scheduled the same way.

Cadence and lookback are tuned per category rather than uniform across all 104: identity and endpoint templates run tight — a 5-minute cadence, 15-minute lookback — because several of these rules cover the kind of attack that is cheapest for an intruder to run against an under-monitored SIEM. Cloud and email templates run wider — 15-minute cadence, 30-minute lookback — since the underlying data is batch audit rows rather than a live session. Network templates carry a shorter, 30-minute suppression window, since these families are high-urgency and comparatively low-volume. A template's schedule can be switched to a cron expression the same way any rule's can, once enabled.

Sigma YAML import

You can also bring your own detection as a Sigma rule. Paste the YAML in, and it is parsed into the same rule shape every shipped rule uses, then wrapped with scheduling metadata exactly the way a template is. A Sigma-imported rule is functionally identical to a hand-built scheduled rule from that point on — same evaluation engine, same tuning surface.

One-click enable, and why it is safe to click twice

Enabling a template from the gallery is idempotent: a second click on a template you have already enabled returns your existing rule instance rather than creating a duplicate. Two different tenants enabling the same template never collide with each other either — each gets its own rule row with a fresh identifier, scoped to that tenant, carrying its own entity mappings, MITRE mapping and severity copied in at enable time.

In the console

SIEM → Scheduled rules (/siem/scheduled-rules) has two tabs.

Your rules

Every scheduled rule your organisation has — hand-authored, Sigma-imported or template-enabled, and there is nothing on the row that distinguishes which route created it once it exists. Shows mode, cadence or cron expression, lookback, when it last ran and what it found, an enabled toggle, an "Edit schedule" action for setting or clearing the rule's cron expression, and an "Import Sigma rule" action that opens a paste-and-submit modal.

Template gallery

All 104 templates grouped into the five categories above, each row showing severity, title, its top MITRE technique ids, and an Enable button — or an "Enabled" pill if your organisation already has an instance of it.

What is not built in the console yet, on the same rules API: a condition-selection builder for hand-authoring a brand-new scheduled rule from scratch — today you can toggle an existing rule, edit its schedule and import via Sigma, but you cannot compose one on the screen — a test-run-against-recent-data preview, rule versions and diff history, YAML export, and the ATT&CK coverage heatmap for this specific gallery (the backend endpoint for coverage exists and is tested; it is not yet rendered).

What happens when one fires

A scheduled rule that fires opens or appends to an incident, the same unified incident object described in How alerts are grouped into incidents. From there, an automation rule can react to it — see Automation rules and proposals for exactly what can and cannot happen automatically, including a distinction that matters here specifically: a scheduled rule fires inside the background worker process, and the worker process handles automation differently from a person working the console.

What to read next

1. Automation rules and proposals — what can run automatically once a scheduled rule opens an incident.
2. Lookups and watchlists — CSV-uploaded reference tables, and why absence mode cannot use one yet.
3. Tuning a detection rule — the threshold/window/cooldown settings on the detection logic a scheduled rule wraps.