Dashboard Snapshots
Home → Security shows a snapshot of retained activity for a fixed time window. Refreshing the view updates that snapshot; it does not establish that every source has collected all recent activity.
Security freshness and cache
Security overview and briefing results are considered fresh for 60 seconds after a successful fetch. When no mounted view uses a query, its cached results remain in the browser's memory for five minutes. Another mounted view using that same query keeps it active. Returning to the same scope and exact time window can show those results immediately. If they are older than 60 seconds, returning to the view requests an updated snapshot in the background. After five minutes without an active view, the results can be discarded and must be fetched again.
This is a reuse policy, not a promise of a new snapshot every minute. Security snapshots do not continuously poll or refresh merely because you focus the browser window. Reloading the page also requires a new fetch.
Results are cached separately for the authenticated session and the exact scope: start and end timestamps, user, agent, session, workload, and cluster filters where supplied. A different identity, workload, or time range cannot reuse another scope's snapshot. Authentication changes clear stored client query results and remount the view, so the previous account's results are not retained on screen.
Progressive loading
Home loads its cards in priority order on Security, top of the page first, rather than requesting everything at once: the security snapshot (summary, trend, protection and coverage) loads first, then the briefing, then the activity counts, then the Cost context card. A card that is waiting for its data shows its own loading placeholder, and cards that have loaded stay visible while others are still loading.
Cost works differently: it requests its four data sets (the overview, the spend series, the request rate series, and the activity heatmap) at the same time, and each card shows its own loading, partial, or error state. See Cost Overview.
If a card cannot be loaded, it shows an error with a Retry button and the rest of the page keeps working. Cards that share one read fail together: on Security, the summary and the protection outcomes come from the same snapshot, so a failed snapshot shows an error in both. A card that failed never shows zero in place of data. A slow or failed card does not hold up the next one for long: the next card starts loading as soon as the previous request fails its first attempt, or after 15 seconds if a request has not answered at all. Changing the window on the Cost view refetches only the cards that depend on it.
The Security snapshot is made of four independent server reads: source coverage, finding groups and trend, gateway request outcomes, and shadow AI exposure. Each is limited to 2 seconds and runs on its own read capacity, apart from analytics queries. A read that does not finish does not fail the snapshot. The cards that depend on it are marked with the reason (Read timed out, Server busy, Rollup preparing, retry later, Couldn’t load source, or Read failed), the other cards show their values, and a Retry button at the top of the snapshot reads again. Failed reads show Couldn’t load. Shadow AI exposure also offers Retry exposure on the card. A failed findings read shows Trend couldn’t load with Retry trend; a successful read without trend data shows Not enough data to show a trend. If only the previous window fails, the selected-window trend remains visible and the card marks Comparison couldn’t load. The shared read warning identifies the failed previous-window comparison separately from a failed current-window read. Not enough data means the read completed but recorded attribution cannot establish the count; its explanation describes the missing data. A missing value is never shown as zero. Server-side results are retried within seconds, because an incomplete snapshot is cached for only 5 seconds. Shadow AI exposure reads closed days from a daily rollup and only the open edges from raw records, so it stays fast on large stores. Until the rollup has been built (for example right after an upgrade), a window longer than 25 hours shows Rollup preparing, retry later for those cards.
The briefing and other finding reads are limited to 10 seconds on the server. A read that exceeds that budget returns an error and the card shows its error state; use Retry or Refresh snapshot to try again.
Shared server cache
The Security snapshot is also cached on the server for 45 seconds, so several people opening Home, Security with the same window and filters share one set of reads instead of each running their own. The cache key includes the exact start and end of the window and every filter (user, agent, session, workload, and cluster), so a different window or scope is read separately. On PostgreSQL deployments with several replicas the cache is shared between replicas, and a snapshot that another replica is refreshing can be shown for a short time with a Shared copy label that gives its age. Access is checked before any cached snapshot is returned. See the Security overview API for the response fields.
As of and Refresh snapshot
As of is the server's snapshot timestamp. The selected window is separate: its start is included and its end is excluded. Reviewing evidence and returning with browser Back preserves that window so you can compare the same records.
Refresh snapshot advances the selected window to the current time while preserving its duration, and requests the corresponding results. This also applies to a custom window restored from a link: refresh does not preserve its original start and end timestamps. It is available even when cached results are still considered fresh. Until you refresh, the displayed time bounds stay fixed, although the records within them can change as sources ingest or update evidence.
A failed refresh may retain a clearly labeled earlier snapshot from the same scope. Read its timestamp before using it for a decision, then retry with Refresh snapshot. An authentication failure or access denial hides cached Security results. An unavailable result is not zero activity.
Cost context freshness
The Cost context card on Home → Security summarizes global spend for a rolling past month, independently of the selected Security window.
| Behavior | Home Cost context |
|---|---|
| Freshness | Five minutes after a successful fetch |
| Inactive cache retention | Five minutes |
| Automatic refresh while the card is mounted | Every five minutes |
| Aggregation backfill | Polls every ten seconds while Calculating spend… is shown |
| Manual refresh | Refresh icon labeled Refresh cost summary |
Loaded at is when the browser received the Cost result, not when the latest underlying spend was recorded. The refresh icon requests a new result immediately. These settings describe the Home summary; individual queries on the full Cost dashboard can have different refresh intervals.
Read the evidence limits
Counts describe retained source records and finding groups, not unique attacks or attacks prevented. Retry attempts can contribute gateway call records. A successful query establishes that its supported records were read; it does not prove complete collection, historical telemetry, or enforcement across the whole estate.
Inspect Sources and evidence limits, Sources and range details, and Exposure qualifications for coverage gaps. Comparisons use an adjacent equal-length window, but missing previous observations remain unavailable. Shadow AI exposure compares recorded traffic with current registration; registration does not prove enforcement or reconstruct historical ownership.
For service health and collection problems, use Monitor System Health. For finding semantics and evidence navigation, see Security Posture.