LEARN. PRACTICE. GROW.Concept and mechanism
A scheduled rule has an execution interval and a lookback period. These are different parameters: frequent execution does not mean querying only the last seconds. When lookback exceeds the interval, windows overlap and an event can be evaluated again. An interval exceeding lookback would leave gaps; scheduled-rule validation prevents that relationship. Also compare event time with ingestion time. Incorrect clocks can distort that difference. Real collection delay needs an appropriate margin, but expanding only the window can duplicate alerts. An ingestion-time condition can associate an event with its intended window, depending on rule design and source delays.
Guided application
In a fictional authentication-failure rule, inspect results after aggregation. If the query returns one row per account, a row threshold does not automatically count every underlying event. Use small examples to confirm intent before enabling the rule. For useful investigation, configure entity mapping and preserve identifiers distinguishing accounts and devices. Columns existing in the query do not guarantee that the interface treats them as entities. Include necessary context in alert details without exposing information the analyst does not need. In the project, record latency assumptions and test criteria so RUN can explain repeated, delayed, or incomplete results.
Nine account-aggregated rows remain nine results even when they represent nine hundred events.
Common pitfalls
Interval as lookback; arrival as generation; rows as original events; columns as automatic entities.
Related topics: Detections and controlled automation · Triage and endpoint response
Validate query semantics and time coverage before interpreting alerts.
Reference: Scheduled analytics rules · SC-200 objectives effective 2026-07-28; Microsoft product documentation reviewed 2026-10-01; 2026-10-21 English update compared separately