Timeline Analysis Calculator

reviewableEvents = sources × eventsPerSource × (1 − dedupRate) × (1 − filterRate); elapsed = (ingestTime + reviewableEvents ÷ (reviewRate × analysts)) ÷ productiveHoursPerDay. A super-timeline merges filesystem, registry, event-log, browser and application artefacts, so the raw event count is the product of sources and per-source volume. Deduplication removes the same action recorded in several places, and known-good filtering removes routine operating-system noise; what survives is the set a human must actually look at. The elapsed figure combines machine ingest time with human review capacity, because only one of those scales by adding analysts.

Timelines fail on the human side, not the tooling: 1.5 million events is a fortnight of review, which is why filtering hard and scoping to a suspected window is the only way most investigations finish.

This calculator takes 8 inputs: Evidence sources in the timeline, Events extracted per source, Duplicate events removed, Known-good noise filtered out, Tool ingest rate, Events an analyst reviews per hour, Analysts on the timeline, Productive analysis hours per day. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.

It is standard practice with a maintained known-good hash set and event allow-list, but it is a risk you accept explicitly. Attackers abuse signed system binaries precisely because they land inside the allow-list, so keep the filtered set retrievable rather than deleted.

It depends on what you are doing. Scanning for a known indicator runs at tens of thousands of events per hour; reconstructing an unknown intrusion narrative, where each entry needs context and correlation, runs closer to a few hundred.