What this calculator works out
This calculator converts an event rate and average event size into raw log volume over a retention period, then applies compression and headroom to give the storage required.
Log growth is linear and relentless, which makes it one of the few storage problems that can be predicted exactly — and one of the most common causes of a full disk taking a service down.
Enter your details
Before you size log storage
- Events per second should be a sustained average, not a peak. Peaks matter for ingest capacity rather than for storage.
- Average event size varies enormously — a terse syslog line might be 200 bytes; a verbose JSON application log 2,000 or more.
- Text logs compress well, commonly 5:1 or better. A conservative ratio gives a safer figure.
- Headroom is not optional. A log volume at 100% stops the service that writes to it.
Log volume grows at a constant rate, so a disk fills on a predictable date — and nothing warns you until it does. The failure mode is severe: services that cannot write logs frequently stop, and a full system volume can prevent login. Rotation, compression and a monitored retention policy are what prevent it, and all three are configuration rather than capacity.
How this calculator works
Rate times size times time, then compression:
Raw GB = events per second × bytes per event × 86,400 × days ÷ 10⁹
Storage = raw ÷ compression ratio × (1 + headroom ÷ 100)86,400 is the number of seconds in a day. The result is in decimal gigabytes, matching how disk capacity is sold.
Worked example: 100 events a second
Using the default figures — 100 events/s at 800 bytes, 30 days retention, 2:1 compression, 20% headroom:
- Raw log volume: 207.36 GB
- Storage required: 124.4 GB
A modest 100 events a second produces over 200 GB a month raw. Double the event rate or the retention and it doubles; do both and it quadruples. Text logs frequently compress better than 2:1 — at 5:1 the same requirement falls to under 50 GB — which is why enabling compression on rotated logs is usually the cheapest capacity decision available.
Common mistakes
- Sizing from peak event rate. Storage follows the sustained average.
- Not enabling compression on rotated logs. It commonly saves 80% or more.
- Logging to the system volume. A full system disk is far worse than a full log disk.
- Setting retention without monitoring. Rotation that silently fails fills the disk anyway.
- Retaining verbose debug logging in production. It can multiply volume tenfold.
Frequently asked questions
How long should logs be retained?
Long enough to investigate an incident discovered late, which for security purposes commonly means months rather than days. Regulatory requirements apply in some sectors and set a minimum. The NCSC recommends retaining logs long enough to support investigation, and the practical constraint is usually storage rather than policy.
Should logs go on a separate volume?
Yes, wherever practical. A full log volume degrades logging; a full system volume can prevent services starting and users logging in. Separating them converts a serious outage into a manageable one, and it costs nothing but partitioning.
How much do logs compress?
Text logs are highly repetitive and commonly compress 5:1 to 10:1 with standard tools. Structured JSON compresses well too. Already-compressed or binary payloads do not. Using a conservative ratio in planning and enjoying the surplus is safer than assuming the best case.
What about centralised logging?
Shipping logs to a central system aids investigation and protects them from an attacker clearing local logs — which is a standard step in an intrusion. It moves rather than removes the storage requirement, and the central store needs the same sizing arithmetic across every source feeding it.
Is what I enter stored?
No. Figures are processed in your browser and never transmitted or retained.
Related tools
References
- National Cyber Security Centre — logging and monitoring guidance, including retention for investigation
- Information Commissioner's Office — retention limits and security obligations for logs containing personal data
Sources are checked at publication and can change — how I choose and check references.