Log retention storage calculator
Turn daily log volume and a retention period into the storage you need: 250 GB a day kept for 30 days is 7,500 GB raw, and at a 0.4 compression ratio it shrinks to 3,000 GB, or 3 TB. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Average daily volume gb
- 250
- Retention days
- 30
- Compression ratio
- 0.4
- Raw storage gb
- 7,500
- Estimated storage gb
- 3,000
- Estimated storage tb
- 3
- Storage saved gb
- 4,500
The log retention storage calculator turns a daily ingestion estimate and a retention policy into a practical capacity figure. Enter the average raw volume generated each day, choose how many days the data must remain available, and optionally apply the stored-size ratio you expect after compression. The result shows raw capacity, estimated stored capacity in gigabytes and terabytes, and projected savings, giving infrastructure, security, and finance teams a common number for early planning.
Start with a representative daily log volume
Use the average raw volume produced during a period that reflects normal operations, expressed in decimal gigabytes. A single unusually quiet day will understate the requirement, while a launch-day spike may overstate steady demand, so a weekly or monthly ingestion average is usually a better planning input. Include every source covered by the retention policy: application events, infrastructure telemetry, audit records, security feeds, and any replicated streams that are stored separately.
The calculator multiplies this daily quantity by the retention period to produce raw storage. It does not infer growth, replicas, indexes, filesystem overhead, or a safety reserve. Those factors depend on the logging platform and should be added after obtaining the baseline.
If volume is expected to rise, run a second scenario with the projected daily figure rather than hiding growth inside the compression ratio. Keeping ingestion, retention, and overhead assumptions separate makes the estimate easier to review, update, and explain during capacity or budget discussions.
Interpret the compression ratio consistently
The optional compression ratio is a stored-size multiplier, not a statement such as “three to one.” Enter 0.4 when compressed data is expected to occupy 40 percent of its raw size; that corresponds to a 60 percent storage saving. Leave the field out to use 1, which represents no compression and keeps the estimated stored capacity equal to the raw requirement.
Ratios must be greater than zero and no greater than one because this calculator models compression rather than expansion. Base the value on measurements from representative logs whenever possible. Also verify whether your platform quotes compression before or after indexing, because indexes and metadata can materially increase physical usage.
The returned savings figure is simply the raw baseline minus compressed capacity, allowing reviewers to see exactly how much of the estimate depends on the compression assumption.
Turn the baseline into a deployable capacity plan
Treat the calculated result as the data-storage baseline for the selected retention window. The gigabyte result is useful for smaller environments and direct comparisons with daily ingestion, while the decimal-terabyte result makes larger estimates easier to discuss. Production sizing commonly needs additional allowances for replicas, searchable indexes, metadata, temporary merge space, snapshots, disaster-recovery copies, and headroom for traffic bursts.
Apply those platform-specific multipliers explicitly after this calculation so they remain visible. For example, a replicated search cluster may need several times the baseline physical capacity even though the retained logical log data has not changed. Compare multiple runs to test shorter retention, improved filtering, or a measured compression improvement before committing spend.
The retention period must be a positive whole number of days; zero or negative values are rejected because they do not describe a storage-retention requirement. Revisit the estimate when ingestion patterns or compliance rules change, and validate final procurement decisions against observed platform metrics rather than relying on an early planning calculation alone.
What you can do with it
Size a new logging cluster
Calculate the logical storage baseline before adding replication, indexing overhead, snapshots, and operational headroom.
Compare retention policies
Run alternative day counts to show how policy changes affect capacity and infrastructure budgets.
Evaluate compression assumptions
Compare measured stored-size ratios and quantify the capacity saved by compression for the same raw log stream.
FAQ
What does a compression ratio of 0.4 mean?
It means stored logs are estimated to occupy 40% of their raw size, producing an estimated 60% saving.
What happens if I omit the compression ratio?
The calculator uses 1, so estimated storage equals raw daily volume multiplied by retention days.
Does the estimate include replicas and indexes?
No. It estimates retained log data only; add platform-specific replication, indexing, metadata, snapshot, and headroom allowances separately.
Which daily volume should I enter?
Use the average raw volume of a normal period, ideally a weekly or monthly average, in decimal gigabytes. A quiet day understates the need and a launch-day spike overstates it. Include every source the retention policy covers, such as audit and security feeds.
How do I choose a realistic compression ratio?
Measure it on representative logs whenever you can. Repetitive text tends to compress strongly, while encrypted values, stack traces, identifiers or data that is already compressed shrink much less, so a borrowed ratio can mislead the estimate.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/dev/log-retention-storage-estimate \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"average_daily_volume_gb":250,"retention_days":30}'const res = await fetch("https://api.kit.forhosting.com/dev/log-retention-storage-estimate", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"average_daily_volume_gb": 250,
"retention_days": 30
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/dev/log-retention-storage-estimate",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"average_daily_volume_gb": 250,
"retention_days": 30
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev/log-retention-storage-estimate", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"average_daily_volume_gb":250,"retention_days":30}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"average_daily_volume_gb":250,"retention_days":30}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev/log-retention-storage-estimate", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"average_daily_volume_gb": 250,
"retention_days": 30
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev.log_retention_storage_estimate",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
Interpret the compression ratio consistently
Repetitive text may compress strongly, while encrypted values, stack traces, identifiers, or already compressed payloads can produce a less favorable result.
Technical questions
What does it cost?
It costs $0.002 per API request and can also run free in your browser on this page.
Can the retention period be zero or negative?
No. Retention days must be a positive integer, and invalid values return an invalid_input error.