From MB Per Day of Logs to the GB Figure on Your Observability Bill
Logging platforms hand you two very different numbers. The dashboard that shows what each service emits reports in megabytes per day, because that is the scale a single service actually lives at. The contract, the quota and the retention policy are all written in gigabytes per month. Between those two views sits a small piece of arithmetic that decides whether a new service is a rounding error or the reason next quarter's observability spend doubles — and it is worth doing before the service ships, not after the invoice arrives.
500 MB/day produces 500 × 30 = 15 000 MB in a 30-day month, which is 15 000 ÷ 1 000 = 15 GB of ingest.Volume Is Line Size × Line Count
Fleets Multiply, Not Add
Retention Turns Daily Into Resident
How to Turn a Daily Log Volume into a Retention Number
Take the Per-Service Daily Figure
Pull the MB/day each service emits from your ingest dashboard, ideally an average over a fortnight so a deploy day or an incident does not set the baseline for everything else.
Multiply by the Window, Then Convert
Multiply the daily MB by 30, 90 or 365 depending on the tier you are pricing, type that total into the left field, and read the gigabyte figure the platform will invoice against.
Copy the GB Figure Into the Model
Each field has its own copy button that returns the bare number, so the value drops into a spreadsheet cell or a capacity ticket without a stray unit breaking the formula.
Work Backwards From a Budget
Given a ceiling instead of a forecast, hit the swap button: put the GB allowance on the left and read the MB it leaves you, then divide by the days in the window to get the daily budget each service has to fit inside.
The reverse direction is the one that actually shapes policy. A 500 GB monthly allowance is 500 000 MB, or about 16 666 MB a day across the whole estate — an abstract cap turned into a per-service number an owner can be held to. Both fields stay live as you type, so you can nudge either side and watch the other move while you negotiate.
Log Retention Volume: Daily MB Against 30, 90 and 365 Days
This table takes a per-service daily emission rate and shows the resident volume at three common retention windows. Commercial log platforms are typically priced somewhere between roughly $0.50 and $2.50 per GB ingested, with hot searchable retention charged on top, so the right-hand column is usually the one that decides whether a policy survives a budget review.
| Daily volume | 30 days | 90 days | 365 days |
|---|---|---|---|
| 50 MB/day | 1.5 GB | 4.5 GB | 18.25 GB |
| 100 MB/day | 3 GB | 9 GB | 36.5 GB |
| 250 MB/day | 7.5 GB | 22.5 GB | 91.25 GB |
| 500 MB/day | 15 GB | 45 GB | 182.5 GB |
| 1 000 MB/day | 30 GB | 90 GB | 365 GB |
| 2 500 MB/day | 75 GB | 225 GB | 912.5 GB |
Read it as a sampling calculator too. A service at 1 000 MB/day sampled at 10% for its highest-cardinality stream drops to the 100 MB/day row, which turns 365 GB a year into 36.5 GB — the single largest lever most teams have, and one that costs nothing but a decision about which lines are worth keeping in full.
Budget-First Planning
Swap the fields to start from a GB allowance and derive the MB/day each team gets, which is how a quota becomes an enforceable per-service number instead of an argument.
Kilobytes to Terabytes on One Scale
Searchable dropdowns on both sides mean a KB-per-line figure and a TB-per-year archive can be lined up without switching pages mid-estimate.
Spreadsheet-Safe Copy
Copying a result gives you the number alone, so a capacity model built cell by cell never picks up a unit string that breaks the next formula down the column.
Live Both Ways
Both fields are editable and update as you type, which suits a retention review where the numbers are being argued over rather than looked up once.
Log Volume Questions SRE Teams Ask
How big is one structured JSON log line in practice?
Most production lines land between 0.5 KB and 2 KB once the standard envelope is included: ISO timestamp, level, logger name, message, trace and span IDs, service and version, plus whatever context the team attaches. Request logs with full headers or a serialised payload run considerably larger. Measure your own rather than guessing — pipe a few thousand real lines to a file and divide, because the envelope is often bigger than the message it wraps.
Does dropping debug lines actually move the monthly gigabyte figure?
Usually yes, and by more than people expect, because debug output is high-frequency rather than high-value. If debug is 70% of a service's 800 MB/day, moving it behind a runtime flag drops the service to 240 MB/day: a 30-day month falls from 24 000 MB to 7 200 MB, which is 24 GB down to 7.2 GB. Drop rules at the collector are usually safer than editing application code, since they can be reverted during an incident.
Why is my billed ingest higher than the size of the log files on disk?
Because the two measure different things. Files on disk are usually compressed and hold only what the application wrote; billed ingest is measured on the uncompressed payload as it arrives at the platform, after the collector has enriched every line with pod, node, cluster, region and account metadata. Fifteen enrichment fields on a 600-byte line is a meaningful percentage increase applied to every line you send, which is why trimming default enrichment is worth checking before you touch application logging.
Should I compare vendors on gigabytes ingested or gigabytes retained?
On both, because vendors do not agree on which one they charge for. Some price purely on ingest and bundle a fixed retention period; others charge a low ingest rate and bill retention separately per GB per month. Take one representative service — say 500 MB/day, so 15 GB a month — and price it through each vendor's own model at your real retention window. Comparing headline per-GB rates without doing that will rank the options in the wrong order.
How much does moving older data to a cold tier change the 365-day number?
It does not change the volume at all, only what that volume costs. A service at 500 MB/day still accumulates 182.5 GB over a year whichever tier holds it. What changes is that perhaps 15 GB stays hot and searchable for 30 days while the remaining 167.5 GB sits in a cheaper archive that is slower to query and often charges per scan. Compliance is usually satisfied by the archive; day-to-day debugging almost never reaches past the hot window, which is what makes the split worth doing.
No comments yet. Be the first to comment!