How many days of SRUM data are typically available?

Roughly 30 days in the short-term tables and up to ~1 year in the long-term (LT) tables, depending on activity volume and registry configuration.

What controls SRUM retention?

The SRUM extension registry under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SRUM\Extensions, plus the Diagnostic Policy Service that schedules commits. There is no single user-facing setting.

Does heavy activity shorten retention?

Effectively yes. SRUM prunes by age, but a very busy system produces more rows per hour, so the practical window of useful detail can feel shorter.

Are the long-term tables always present?

The {…}LT tables exist on most Windows 10/11 builds. They aggregate the short-term rows on a weekly cadence, so granularity is lower but reach is much longer.

Can retention be changed by an attacker?

An attacker with admin rights could alter the registry or stop the service, but that itself is an indicator. Compare row-count continuity and TimeStamp gaps against expected activity.

← Back to parser

How long does SRUM keep data? Retention and registry settings

5/19/2026

The practical answer

Short-term tables (Application Resource Use, Network Data Usage, etc.): about 30 days of hourly-bucketed rows.
Long-term tables (the {…}LT siblings): up to roughly a year, aggregated weekly.

These are not hard guarantees — retention is a function of age-based pruning and how many rows the system generates.

What governs it

There is no "keep SRUM for N days" checkbox. Retention emerges from:

The Diagnostic Policy Service (DPS) — schedules the periodic flush (hourly by default, every ~10 s on power-state change).
The SRUM extension registry — HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SRUM\Extensions lists each GUID-named extension and its parameters.
Pruning — old rows are dropped as the database is maintained; the LT tables receive the aggregated rollups before short-term rows age out.

What this means for an investigation

An incident older than ~30 days likely only survives in the LT tables — expect weekly aggregates, not hourly detail. Check both when you parse the database.
A gap in the TimeStamp sequence where you'd expect activity is itself evidence: service stopped, system off, or tampering. Cross-check with the Energy Usage table's power-state events.
Don't over-claim precision. A single 30-minute session can appear as one hourly bucket — see Using SRUM in a forensic investigation for the resolution caveats.

Verifying retention on a sample

Open the database in the parser, sort the Application Resource Use table by TimeStamp, and read the earliest and latest rows. That span is your actual usable window for this specific machine — far more reliable than assuming "30 days".

Frequently asked questions

How many days of SRUM data are typically available?: Roughly 30 days in the short-term tables and up to ~1 year in the long-term (LT) tables, depending on activity volume and registry configuration.
What controls SRUM retention?: The SRUM extension registry under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SRUM\Extensions, plus the Diagnostic Policy Service that schedules commits. There is no single user-facing setting.
Does heavy activity shorten retention?: Effectively yes. SRUM prunes by age, but a very busy system produces more rows per hour, so the practical window of useful detail can feel shorter.
Are the long-term tables always present?: The {…}LT tables exist on most Windows 10/11 builds. They aggregate the short-term rows on a weekly cadence, so granularity is lower but reach is much longer.
Can retention be changed by an attacker?: An attacker with admin rights could alter the registry or stop the service, but that itself is an indicator. Compare row-count continuity and TimeStamp gaps against expected activity.