Manage your rule run schedule

Supported in:

This document is for security analysts and engineers who want to manage rule run schedules within Google Security Operations. It explains how to configure frequency settings—from real-time scanning to 24-hour scheduled intervals—and how to interpret the background runs that process late-arriving data.

Common use cases

Choosing the right schedule depends on the severity of the threat and the complexity of your logic. Most teams prioritize their schedules based on the following objectives.

High-priority alerting

  • Objective: Detect critical threats the moment they hit the platform.
  • Value: Reduces attacker dwell time for single-event matches that require no additional context.

Complex correlation and reporting

  • Objective: Run rules that require counts, sums, or multi-event windows.
  • Value: Makes sure that the system ingests and enriches all related logs before execution, providing more accurate alerts for compliance and trend analysis.

Before you begin

Before you modify any schedules, ensure your environment meets the following requirements to avoid configuration errors.

  • Permissions: You must have the Chronicle API Admin (roles/chronicle.admin) or Chronicle API Editor (roles/chronicle.editor) role to modify rule schedules.
  • Environment check: Make sure your logs are correctly mapped to the Unified Data Model (UDM) to support scheduled interval aggregations.

Key terminology

To better understand how the system handles timing, familiarize yourself with these platform-specific terms.

  • True-up runs: Automatic background executions that re-evaluate rules to capture data that arrived late or required extra time for enrichment.
  • Enrichment: The process of adding context to a log, such as asset metadata or user identity, which may happen shortly after the initial ingestion.

Understand rule run scheduling

Google SecOps automatically determines the available scheduling options based on your rule logic. The Run Schedule menu only displays options compatible with your specific rule type (for example, single-event vs. multi-event).

Default schedule configuration

The system evaluates events after they arrive based on the following schedule. This delay makes sure data completeness and account for ingestion or enrichment latency.

Schedule Assignment criteria Evaluation timing True-up cycles
Real-time (10m) Single-event or match window < 1h Shortly after arrival No. Evaluates late/enriched data in standard execution.
Hourly (1h) Match window between 1h and 48h 1 to 2 hours after arrival Yes. Includes 5-hour and 24-hour stages.
Daily (24h) Match window > 48h 24 to 25 hours after arrival Yes. Includes 5-hour and 24-hour stages.

Learn more about how to configure customized schedules for rules.

Automatic true-up stages

To prevent missed detections due to ingestion delays or late enrichment, the system automatically performs "true-up" runs for multi-event rules:

  1. Initial run: Executed as quickly as possible to expose immediate threats.
  2. Intermediate run (~5h): An additional run occurs approximately five hours after the event. Note: This stage doesn't wait for full data enrichment.
  3. Final true-up (~24h): Executed once all additional data and enrichment are confirmed (100% visibility).

Note: Single-event rules process late-arriving and enriched data during standard execution and doesn't use 5-hour and 24-hour true-up cycles.

Change the run schedule

To change how often the system evaluates your custom detection logic, do the following:

  1. In Google SecOps, go to Detection > Rules & Detections.
  2. Click Rules Dashboard.
  3. Open the More more_vert menu for your rule.
  4. Select a Run Schedule value from the menu (for example, 10 minutes).
  5. Click Save. The system saves your changes automatically.

Identify detections

Once a rule is active, you can distinguish between initial alerts and those generated by the system's automatic re-runs.

  1. Go to the Alerts page or Rules Dashboard.
  2. In the Detection Type column, click Lightbulb to see if the detection originated from an initial run, a true-up run, or a retrohunt.

Troubleshooting

Review the dimensions of your data to investigate why specific detections appear or change over time. While the system identifies most threats immediately, certain data nuances require background processing to provide full accuracy. Understanding these background runs helps you accurately measure your Mean Time to Detection (MTTD) and verify the integrity of your alerts.

Latency and limits

Rule run frequency directly impacts the speed of your detections. Less frequent schedules increase the time between when an event occurs and when the system processes a detection.

  • Hourly schedules: These run every hour using the most recent data available; there is no buffer applied.

  • Daily schedules: The system introduces a 24-hour buffer to ensure complete data ingestion before processing.

Discrepancies between runs

The initial run of a rule might not identify a detection that later appears during a true-up run. This behavior ensures that the system identifies most threats immediately while allowing for high-fidelity confirmation later. Common causes include:

  • Data ingestion latency: Log data arriving after the first run completes.
  • Enrichment completeness: Context from external sources (asset metadata or identities) still processing during the initial run.
  • Timing adjustments: True-up runs wait for the most complete dataset before executing. Detections in the first run might arrive later than expected.

Error remediation

Use this table to resolve common issues related to missing customization options or restricted schedules.

Issue Cause and Fix
Missing custom schedule options Single-event rules use the real-time engine and don't support scheduled intervals. Additionally, Curated rules follow fixed system schedules that you can't modify.
Unsupported intervals If you cannot select Near Real-time, your rule likely uses a match section or aggregations (such as count or sum). These functions require scheduled intervals to process data over time.

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