Issue

When using scheduled rules in Panther, signals from scheduled queries may not appear in the signal search results, even when the query is returning data and the rule logic is working correctly. This is particularly noticeable when the scheduled query processes historical data or has a large lookback window.

Resolution

To properly view signals from scheduled rules:

1. Use the Data Explorer to search for signals

2. Filter using the p_alert_update_time field instead of the default timestamp fields

Cause

This behavior occurs due to how timestamp fields are handled in scheduled rules. Here's how the different timestamp fields work:

• p_alert_update_time - Set when the signal (or rule match) is created

• p_alert_creation_time - Marks the beginning of the deduplication period for the rule, i.e. when the first signal in that deduplication period was created

• p_event_time - Provided by the original log. For scheduled queries, the query may not retrieve this field (or may query a table that doesn't have this field), in which case it will be populated by default to p_alert_update_time

• p_parse_time - When the log is ingested into Panther. For scheduled queries, the query may not retrieve this field (or may query a table that doesn't have this field), in which case it will be populated by default to p_alert_update_time

Additional context about the alert timestamps can be found in the corresponding section from our documentation.

By default, signal searches look for events within specific bounds of p_event_time. While this works well for real-time/streaming rules, events from scheduled queries that process historical data may fall outside these bounds and won't appear in the default search results. Using p_alert_update_time ensures you can find all signals when they are created, regardless of the original event time.