Starlight Tools
Measure at the storage boundary
Application payload, collector traffic, and stored chunks can differ. Measure the closest reliable stage, then apply only the transformations that occur after it.
Log Storage Calculator
Estimate storage for application logs, security events, observability telemetry, and audit records from ingestion rate, retention, compression, stored copies, index overhead, and operating headroom.
Storage estimate
Capacity to provision
Including copies, overhead, and free-space headroom.
Daily logical ingest
—
Retained logical data
—
Compressed payload
—
Stored before headroom
—
| Stage | Capacity |
|---|---|
| Retained logical logs | — |
| Compression savings | — |
| Compressed payload | — |
| All stored copies | — |
| Index / metadata overhead | — |
| Free-space headroom | — |
| Provisioned capacity | — |
Results show decimal and binary units for the same byte count. They do not include a separate backup, cross-region copy, search cache, or transient migration space unless represented in your assumptions.
Advertisement
Advertisement
Compare common retention periods
The table keeps ingestion, compression, copies, overhead, and headroom unchanged, then varies only retention. Use it to see the storage effect of policy changes.
| Retention | Logical logs | Capacity to provision |
|---|---|---|
| Enter valid assumptions to compare retention periods. | ||
Formula and assumptions
logical bytes = ingest bytes per second × retention seconds
compressed payload = logical bytes ÷ compression ratio
all copies = compressed payload × total stored copies
stored before headroom = all copies × (1 + index overhead ÷ 100)
provisioned capacity = stored before headroom ÷ (1 − headroom ÷ 100)
Headroom is divided by the usable fraction, not merely added. For example, keeping 20% free means modeled data may occupy 80% of provisioned capacity, so the required capacity is stored bytes ÷ 0.80.
Important: this is a steady-state capacity model. It does not size ingest CPU, memory, IOPS, shard counts, query performance, network bursts, write-ahead logs during failure, or temporary disk needed for compaction and migration. Validate production sizing with observed data and platform guidance.
Worked example
At 5 GB/day for 30 days, the logical retained volume is 150 GB. With 3:1 compression, that becomes 50 GB per copy. Two stored copies require 100 GB; 15% index and metadata overhead raises modeled use to 115 GB. Keeping 20% free requires 115 GB ÷ 0.80 = 143.75 GB of provisioned capacity, equal to about 133.88 GiB.
Choose defensible inputs
Benchmark compression
Structure, repetition, timestamp precision, stack traces, and encrypted or encoded fields change compression. Test representative production segments rather than copying a generic ratio.
Separate tiers
Run hot, warm, and archive tiers separately when their retention, compression, copies, or overhead differ. Add their provisioned results afterward.
Verify deletion behavior
Expired logs may be removed asynchronously. Compaction and object lifecycle delays can create temporary storage above this steady-state estimate.
Platform references
Use platform documentation to replace planning assumptions with measured or supported values. Grafana explains that Loki stores compressed chunks plus indexes and that retention-driven deletion is performed asynchronously by the Compactor. Elastic’s capacity-planning material likewise treats source volume, indexing/compression factors, replicas, disk thresholds, and error margin as separate sizing inputs.
Log storage calculator FAQ
How is log storage calculated?
Logical retained data equals ingestion bytes per second multiplied by retention seconds. The calculator divides by compression, multiplies by total stored copies, adds index and metadata overhead, then divides by the usable fraction remaining after headroom.
What compression ratio should I use for logs?
Use a ratio measured from representative production logs on the intended platform. A 3:1 ratio means three logical bytes occupy one compressed byte. Use 1:1 when no reliable measurement exists.
Does one replica mean one or two stored copies?
One primary plus one replica means two total stored copies. This calculator asks for total copies so the multiplier is explicit.
Why add index and metadata overhead?
Logging platforms may store indexes, labels, segment metadata, transaction logs, caches, or other structures in addition to compressed log payloads. The amount depends on the product and data shape.
Should I use average or peak ingestion?
Use a representative sustained average for retained capacity, then run a peak or growth scenario separately. Storage bandwidth, queues, and ingest nodes must also survive bursts even when long-term volume is based on an average.
Why are TB and TiB different?
A decimal TB is 1,000,000,000,000 bytes. A binary TiB is 1,099,511,627,776 bytes. The calculator converts through bytes and reports both systems.
Does changing retention immediately free storage?
Not necessarily. Many systems delete expired data asynchronously through compaction, lifecycle, or cleanup processes, so actual usage can lag the configured retention period.
Are inputs uploaded or tracked?
No. The calculation runs locally in the browser and does not send entered workload values to a server.
Method and review notes
Methodology: byte-based steady-state capacity model
Last reviewed:
Reviewer: no individual technical reviewer is claimed
Use this estimate for early planning and scenario comparison. Validate procurement and production limits against measured ingest, platform retention behavior, storage architecture, failure domains, query requirements, and vendor sizing guidance.