Skip to main content
Question

Working of time filter of IOC model data in dashboards

  • June 9, 2026
  • 2 replies
  • 49 views

harshal.thakor
Forum|alt.badge.img+4

Hi,

I wanted to know global time filter of the Google SecOps SIEM dashbaord works on which field of IOC model if we have only IOC model data coming from IOC matches?

Also, I have one observation that , match which is visible in IOC match table which is not returning while quering through dashboard for same time range?

2 replies

dnehoda
Staff
Forum|alt.badge.img+18
  • Staff
  • June 14, 2026

Which field does the Global Time Filter target?

When you apply a global time filter to a dashboard querying the IOC model/Explore, it anchors to the ioc.day_bucket_seconds field.

Unlike raw UDM events that use microsecond-precise timestamps (metadata.event_timestamp), the IOC matching database aggregates hits into daily blocks.

  • ioc.day_bucket_seconds takes the original timestamp of the log event that caused the match and rounds it to the nearest Unix seconds value for midnight UTC on that specific calendar day.

  • If you query a dashboard for "Today" or "Last 7 Days," Looker evaluates whether the daily bucket integer falls inside those UTC boundaries.

2. Why do matches show in the UI table but disappear from the Dashboard?

If you have a match clearly visible in your Alerts & IOCs table, but it is invisible in a dashboard set to the exact same time range, it is almost always caused by one of these three architectural behaviors:

Reason A: The Ingestion Pipeline Delay (Real-Time vs. Batched)

  • The IOC Match Table reads directly from Google SecOps' real-time evaluation memory. The second a match happens, it flashes into the UI.

  • SIEM Dashboards (both legacy Looker-embedded and Native Dashboards) run queries against the Chronicle Data Lake (BigQuery).

  • Data from the active evaluation pipeline is exported to the Data Lake on an hourly batched schedule. If an IOC match happened within the last 60–90 minutes, it will show up in your main UI table but won't exist in the dashboard backend yet.

Reason B: Retroactive Match Time Placement

Google SecOps continually scans historical logs against newly received threat intelligence feeds (retroactive matching).

  • If a threat intelligence feed adds a malicious IP address today, SecOps will flag it immediately in your UI table.

  • However, if the actual firewall log communicating with that IP occurred 3 days ago, the match's day_bucket_seconds is stamped with the date from 3 days ago.

  • If your dashboard filter is set to "Last 24 Hours," that match will be dropped from the dashboard view because its data bucket sits 3 days in the past, even though the match was technically discovered today.

Reason C: Timezone and Day-Bucket Skew

The global dashboard filter works entirely in UTC based on midnight-to-midnight day boundaries. The Alerts & IOCs page maps to your local browser/console timezone settings.

If an event occurs close to the edge of a day boundary in your local time, the rounding behavior of day_bucket_seconds can push that hit into the previous or next calendar day in UTC. This makes it fall just outside your dashboard's strict filter window.

Tip for Custom Dashboards: If you are building custom widgets for IOC data, try expanding your dashboard filter logic to use a slightly wider window (or incorporate an ioc.ioc_ingest_time or ioc.commit_timestamp column if you want to track when the alert itself arrived in the system) to prevent day-bucket drops.


harshal.thakor
Forum|alt.badge.img+4

As per our observation, the IOC match table data to get reflected on dashboard taken time nearly 3 days rather than 90 minutes. Would it be some instance issue or expected behaviour?

On first day, IOC match table has more number of match than dashbaords.
On third day, IOC match count were same in IOC match table and dashbaords.