Understand rule run scheduling

Supported in:

Google secops SIEM

This guide is for Security Engineers and Developers who want to manage rule performance by understanding automated execution scheduling. In Google SecOps, the system automatically manages rule execution scheduling to ensure system stability and processing efficiency. This document explains how your YARA-L rule configurations determine the system's processing frequency. By following these mapping principles, you reduce detection latency and minimize resource contention. Successful scheduling dramatically reduces time-to-triage for critical threats, and provides a critical business benefit through optimized automated detection.

To maintain optimal performance across thousands of rules, Google SecOps uses automated scheduling to prevent resource contention. The automation provides the following capabilities:

• System stability: Dynamic resource allocation prevents platform-wide latency.

• Processing efficiency: The system balances near real-time streaming for critical threats with optimized batch processing for long-term trends.

• Deterministic frequency: The frequency is predictable and determined by your rule's match window.

Key terminology

• Deterministic frequency: A predictable execution interval the system assigns based on your rule's match window.

• Detection delay: The time difference between event ingestion and rule evaluation.

Before you begin

Before you begin, confirm the following prerequisites are met:

• Permissions: You must have view access to the Rules dashboard in Google SecOps.

View rule execution frequency

1. Go to the Rules dashboard to verify how the system scheduled your rule.

2. Open the Rules dashboard in Google SecOps and locate your rule in the list.

3. View the Run frequency column to identify the system-assigned interval.

Note: The system assigns this value automatically upon rule activation.

Note: If you can't find a run frequency for a specific rule, verify that the rule is active. The system manages start times internally and only assigns the frequency once you toggle the rule to an active state.

Define the rule run frequency

The time window you define in your YARA-L rule determines its run frequency. This action maintains system stability by balancing near real-time streaming with batch processing. To define your time window, complete the following steps:

1. Review your rule's match section to identify the window size.

2. Map your window size to the system frequency (for example, No window = Near real-time).

Caution: If you define a multi-event rule with a small window (for example, 5m or 15m), the system still runs the rule hourly. This acts as the solution to prevent resource contention across the platform.

Schedule run mapping

The run frequency depends on the complexity and time window defined in your YARA-L rule. Use the following table to understand how your rule configuration affects system execution.

Rule type and window size	Execution frequency	Use case example
Single-event rule (no match window)	Real-time	Immediate alerting on critical indicators (IOCs).
Multi-event rule (window <= 48 hours)	Hourly	Detecting brute force attempts over a short window (for example, 15m and 1h).
Multi-event rule (window > 48 hours)	Daily (24 hours)	Monitoring slow exfiltration over several days.

Example: Multi-event rule with hourly execution

The following example demonstrates a multi-event rule that the system executes hourly due to the 15-minute window:

  rule fifteen_minute_window_example {

  meta:
    description = "Runs hourly because window is <= 48h"

  events:
    $e.metadata.event_type = "USER_LOGIN"
    $e.principal.user.userid = $user

  match:
    $user over 15m

  condition:
    $e
}

System behaviors and limitations

• No custom intervals: You can't configure a rule to "run every 10 minutes" or "run at 2 am." The system manages all start times internally.

• Detection delays: Detection delays can vary based on data ingestion speeds. For more information, see Understand rule replays and MTTD and Understand rule detection delays.

• Late-arriving data: Single-event rules evaluate all arriving data regardless of latency. Multi-event rules stop evaluating after the last run, which is typically 24 to 30 hours after the event hour.

Need more help? Get answers from Community members and Google SecOps professionals.