Poller Timing
A poller is a scheduled job that regularly checks a data source (like a SIEM, ticketing system, or email inbox) for new events. Each time it runs, it queries the data source for events within a specific time window â a "from" and "to" timestamp. Three settings control exactly how that window is calculated.
Quick Referenceâ
| Setting | What it controls | Effect on window |
|---|---|---|
| Frequency | How often the poller runs | Sets the base window size |
| Window Offset | How far back the window ends | Shifts the entire window backwards |
| Lookback Range | How far back the window starts | Widens the window at the start |
Interactive Diagramâ
Use the sliders below to see how each setting shapes the query window.
Polling Frequencyâ
The most basic setting is how often the poller runs. With no other settings configured, the query window is simply:
- From: the last time the poller ran
- To: right now
The minimum supported frequency is 30 seconds.
The query window always covers exactly the gap since the last run. This means if the poller was down for an hour, the next run will automatically query from 1 hour ago to now â no events are skipped.
Window Offsetâ
Since polling windows don't intersect, any event that falls in a window the poller already queried will never be looked at again. This becomes a problem when a data source has an ingestion delay â an event might happen at time T, but not appear in the API until T+5 minutes. If the poller already queried up to T and moved on, that event will be missed permanently.
The window offset shifts the entire query window backwards by a set amount. The window keeps the same size, it just ends a little in the past instead of at the current moment, giving the data source time to catch up before the poller asks for data.
For example, with a 30-minute frequency and a 10-minute offset:
- From: 40 minutes ago
- To: 10 minutes ago
Lookback Rangeâ
The lookback range extends the start of the query window further into the past, without moving the end. This makes the window wider.
For example, if a poller runs every 30 minutes with a 60-minute lookback:
- From: 90 minutes ago
- To: now
This is useful when events can arrive very late â for instance, an audit log entry might not appear in the API until 45 minutes after it happened. Without lookback, those entries would fall outside the query window entirely.
Window Offset vs. Lookback Rangeâ
| Window Offset | Lookback Range | |
|---|---|---|
| What moves | Both start and end shift back | Only start shifts back |
| Window size | Unchanged | Wider |
| Response time | Always delayed by the full offset | Events ready early are picked up immediately |
| Use when | The data source is never reliable before N minutes (e.g. a pipeline that always batches on a delay) | The data source is usually ready quickly but can occasionally be late |
| Trade-off | Consistent delay on every event | May see the same event across multiple runs (deduplicated automatically) |
A wider query window means the same event might be returned across multiple runs. The poller automatically deduplicates results, so re-fetching an event doesn't create duplicate investigations.