Log Storage Calculator
Gigabytes a day times retention, squeezed by the ratio log text actually earns — the archive, priced.
Log Storage Calculator
Results recalculate instantly on every keystroke. Nothing you type is transmitted.
What this result does not account for
- Steady daily volume — no burst modeling
- Tier rates are warm/cold object-storage conventions
In short: Twenty gigabytes of logs a day held for 90 days is 1,800.000000 GB raw — and log text compresses about 10:1, so the archive stores it in 180.000000 GB. Every extra retention day adds 2.000000 GB stored. At the warm tier's $0.004 a GB-month the archive runs $0.720000 monthly; the cold tier at $0.001 drops it to $0.180000. Compress first, tier second — that order is the whole trick.
Formula
raw GB = per-day × days ··· stored = raw ÷ ratio
Logs are the machine's exhaust: repetitive, timestamped plaintext that compresses better than almost anything else you store — about 10:1 on gzip, 8:1 quoted as the conservative field figure. Retention multiplies the daily line first; the ratio divides it once. The tier prices use warm and cold object-storage conventions because that is where archives live: compress before the cold tier, never after, or you pay full freight for bytes that were mostly repetition.
Worked Example
- Enter the raw gigabytes a day.
- Enter the retention window in days.
- Pick the compression your sample earned.
- Read the archive, the daily cost and the tiers.
Defaults: 20 GB/day for 90 days at 10:1 → 180.000000 GB stored. Drive 5 GB/day for a year → 1,825.000000 raw, 182.500000 stored — compliance years are cheaper than they feel.
Strengths & Limits Of This Model
Where this engine is strong
- Raw-vs-stored split kept visible
- Per-retention-day cost made explicit
Where it stops
- Ingestion and query fees of live platforms excluded
Practical Use Cases
Retention policy
the disk cost of one more day
Compliance budgets
the year-long archive, priced
Pipeline checks
before-vs-after compression
Methodology & Editorial Standards
Computation runs in IEEE-754 double precision at full internal precision; rounding to two decimal places occurs strictly at the display layer, so no cumulative drift enters the result. All monetary outputs use accounting presentation — grouped thousands, two decimals, negatives in parentheses — so figures can be transcribed directly into a model or working paper. Division-by-zero and out-of-domain inputs return an em-dash rather than a misleading number.
This engine was reconciled against an independent reference implementation and hand-verified for the worked example above before release. Our full five-stage review process is published on the About Us page.
Disclaimer. This calculator is provided for informational and modelling purposes only and does not constitute financial, tax, legal, medical, or engineering advice. Verify all figures with a qualified professional before acting on them.
Log Storage Calculator — 8 Expert FAQs
8 analyst-written answers to the questions practitioners actually ask — optimised for voice and answer-engine retrieval.
How much storage do logs need?
Multiply the daily raw volume by retention days, then divide by the compression you actually measured. Twenty gigabytes a day for 90 days is 1,800.000000 GB raw, about 180.000000 GB stored at log text's typical 10:1. The division is small; the habits around it are what cost money.
Why do logs compress so well?
They are plaintext built from templates: the same field names, level words, endpoints and timestamp shapes repeat millions of times, which is exactly the redundancy gzip eats. Ratios near 10:1 are routine, 8:1 is the conservative field quote, and structured columnar formats reach further still. Measure your own sample once and enter that ratio.
What does retaining logs for a year cost?
Five gigabytes a day for 365 days is 1,825.000000 GB raw — about 182.500000 stored at 10:1. On the warm tier at $0.004 a GB-month that is under a dollar a month; the cold tier prices it in cents. Compliance retention is rarely a storage problem; it is a retrieval-discipline problem.
Should logs be compressed before archiving?
Always: compression before the archive tier is the single largest lever in log economics, because the cold tiers bill by the gigabyte and log text is mostly repetition. Compressing after archival, or never, pays full price for ten copies of the same template. The order — compress, then tier — is the entire trick.
What retention period should I keep?
Whatever your compliance and debugging reality demands, tiered by temperature: recent logs hot for days, the quarter warm, the compliance year cold. Every extra retention day on the defaults here adds 2.000000 GB stored — small alone, multiplied by every service, the number that surprises budgets at review time.
Why is my log storage bill larger than this?
Because live log platforms charge ingestion and query rates far above object storage, and uncompressed hot retention is the most expensive way to hold bytes. Route the archive tier through compressed object storage and keep the interactive platform for the recent window only — the tier read here prices that split.
Do all logs compress at 10:1?
No — debug-heavy text with stack traces squeezes harder, while already-structured binary or JSON-with-unique-IDs streams compress less. Run one day's sample through gzip and enter the ratio you measured; the chips are conventions for planning, and the field exists because your exhaust is not my exhaust.
How does this differ from the cloud storage calculator?
That page prices an arbitrary footprint at your chosen rate; this one starts one step earlier — raw daily volume times retention, divided by compression — because log archives are the classic case where the footprint itself is a choice. Price the squeeze here, then carry the stored figure there for the full tier bill.