What this tool helps you work out
Windows Event Logs are often most valuable after something has already gone wrong. If a log is too small, the entries needed for troubleshooting may have been overwritten before anybody begins investigating.
This calculator estimates a suitable log size from the number of events written each day, an average event size and the number of days you want to retain. It is a capacity-planning tool rather than a guarantee: event sizes and activity can change sharply during faults, updates or security incidents.
Enter your details
Before you choose a log size
Decide which log you are planning. The Security log on a domain controller may grow far faster than the Application log on an ordinary workstation. Measure the real growth rate where possible, then add headroom for unusually busy periods.
When a log reaches its maximum size, Windows follows the configured retention behaviour. It may overwrite old events, archive the log, or stop accepting new entries until it is cleared.
How the estimate is calculated
Required bytes = events per day × average bytes per event × retention daysThe calculator then adds the selected headroom and converts the result into practical storage units. The average event size should include the event record overhead rather than only the visible message text.
Worked example
A server writes 80,000 Security events each day. If the average stored event is 1.2 KB and 14 days of local history are required:
- 80,000 × 1.2 KB = 96,000 KB per day
- 96,000 KB × 14 days = about 1.28 GB
- Adding 25% headroom gives a target of about 1.6 GB
A central log collector may still be needed where retention or security requirements exceed what should be kept locally.
Common event-log planning mistakes
- Using a single size for every channel without measuring its activity.
- Planning from a quiet day and ignoring update, audit or incident spikes.
- Increasing the maximum size without checking the overwrite or archive policy.
- Keeping important audit evidence only on the computer being investigated.
- Forgetting that verbose diagnostic channels can grow extremely quickly when enabled.
Frequently asked questions
How large can a classic Windows event log be?
Microsoft's Limit-EventLog documentation accepts a value between 64 KB and 4 GB for the classic logs managed by that cmdlet. Other channels and modern tooling may have different practical constraints.
Should I set every log to 4 GB?
No. Large logs take disk space and can be slower to move or inspect. Size each important channel according to measured growth and required retention.
What happens when a log is full?
That depends on the retention setting. Windows may overwrite the oldest records, archive the log or stop recording new events.
How can I measure real daily growth?
Record the log file size at the same time on several representative days, or export event counts with PowerShell and compare them over time.
Is local retention enough for security logs?
Not always. Important systems commonly forward events to a central collector or SIEM so an attacker or disk failure cannot remove the only copy.
Related Windows and technology tools
References
These sources support the Windows behaviour or command guidance discussed on this page.
- Microsoft PowerShell: Limit-EventLog
- Microsoft .NET: EventLog.MaximumKilobytes
- Microsoft: Event log security through local policy or Group Policy
External documentation can change. Check the linked source before applying a setting to an important system.