# Reconcile a Log Analytics volume spike against receipt time before changing collection

> Why can an ingestion-volume increase be missing from records grouped by event time?

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-498-reconcile-a-log-analytics-volume-spike-against-receipt-time-before-changing/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:23:38+00:00
- Modified: 2026-09-10T02:08:05+00:00
- Last reviewed by DSE: 2026-09-09
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, IT
- Reading time: 2 minutes

## What you need to know

Why can an ingestion-volume increase be missing from records grouped by event time?

## Potentially affected

Log Analytics investigations comparing Usage records with raw records grouped by TimeGenerated.

## DSE recommendation

Compare receipt time with event time for the implicated table before interpreting the mismatch as changed workload activity.

## Article

## Source facts

A Log Analytics Usage increase can disagree with raw-record totals grouped by TimeGenerated when older events arrive late. Microsoft gives disconnected agents sending accumulated data and incorrect host clocks as examples. The _TimeReceived field records arrival at Azure Monitor; comparing it with TimeGenerated helps investigate that discrepancy. Usage’s StartTime and EndTime describe its reporting buckets. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-monitor/logs/analyze-usage).

## Applicability

Use this investigation when receipt-oriented usage and event-time analysis disagree. The examples are possible explanations, not a diagnosis of the organization’s hosts. Identify the affected table and interval before widening the search or assuming new activity occurred at the same time as ingestion.

## DSE recommendation

Compare receipt time with event time for the implicated table before interpreting the mismatch as changed workload activity. Ask the collection owner to retain the spike interval and the query definitions used on both sides. Examine the event-time distribution within that receipt interval, then relate any older records to actual agent connectivity and clock evidence. Avoid immediately reducing collection to hide a spike whose origin is still unknown.

## Verification

Run a bounded table-specific comparison and preserve the arrival interval, event-time grouping and observed record totals. Confirm that the query’s time scope can include the older events being investigated. Document whether the evidence supports delayed delivery, a timestamp problem, another explanation, or an unresolved mismatch. Do not label historical records as newly generated solely because they became visible during the spike.

## Official references

[Microsoft Learn: Analyze Log Analytics usage](https://learn.microsoft.com/en-us/azure/azure-monitor/logs/analyze-usage). Source reviewed September 9, 2026.

## Primary reference

- Name: Analyze usage in a Log Analytics workspace in Azure Monitor - Azure Monitor | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/azure-monitor/logs/analyze-usage
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Reconcile a Log Analytics volume spike against receipt time before changing collection,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-498-reconcile-a-log-analytics-volume-spike-against-receipt-time-before-changing/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.