You have a scheduled rule configured with a deduplication period specified and an event threshold. However, you see the rule generating alerts even though the number of events is lower than your threshold. This goes against intuition regarding thresholds and deduplication, as described in our documentation here.
This problem can be solved by ensuring that the Deduplication Period of the Scheduled Rule is shorter than the period of the Scheduled Query. In other words, if your Scheduled Query runs every 30 minutes, then you must ensure that your Deduplication Period is shorter than 30.
The cause of this behaviour is that if a Scheduled Rule matches the same event multiple times (such as when a Query's look-back period is greater than its frequency), Panther considers all matches to count separately towards the threshold count. However, if an Alert is generated, the Events tab (as shown in the screenshot above) only lists the number of unique events, and doesn't consider how many times each event matched the detection.
By adjusting the Deduplication Period to be shorter than the Query's frequency, you ensure that no matches from the current run will persist to be added to the matches from the next run. For example, setting the dedup. period to 20, when the rule runs every 30 minutes, means that 20 minutes after the last rule run, Panther will drop any current rule matches and reset the threshold to 0. When the rule runs next, any matches will be adding up from scratch again.