Workload inputs
Count logical rows after application sampling and filtering.
Use a measured serialized payload average when available.
Months of events to include in the estimate. This does not set your retention policy.
Aggregate query runtime across the team.
Published paid-plan prices are shown per user per month.
Planning result
3 GB
estimated retained event payload
Free
Over limit
Includes 1 GB and 1 query hour.
Business
$39.00
$36.00 seats + $0.00 storage + $3.00 query.
Enterprise
$297.00
$297.00 seats + $0.00 storage + $0.00 query.
Estimates use published monthly list prices and simple decimal gigabytes. They exclude taxes, discounts, negotiated terms, compression, schema overhead, deletes, and workload changes. This is a planning tool, not an invoice or quote.
See how we calculate the estimate
The formulas below show how each input affects the total. Use measured production values when you have them.
- 1
Monthly payload
5,000,000 events × 200 average bytes.
- 2
Retained storage
Monthly payload × 3 months = 3 decimal GB.
- 3
Included usage
Subtract each plan's included storage and query-hour allowances from your estimated usage before calculating overage.
- 4
Monthly estimate
Add 3 user seats, storage at $0.03/GB-month, and query overage at $0.30/hour.
Calculation model
Reproduce the estimate outside this page
Retained payload is monthly events multiplied by average serialized bytes and retention months, divided by one billion. The calculator uses decimal gigabytes because the published storage allowance and overage rate are expressed in GB.
For a paid plan, seat cost is users multiplied by the current monthly per-user price. Storage and query charges apply only to usage above that plan's included amounts. Negative overages are clamped to zero before the three components are added.
stored_gb = events × bytes × retention_months ÷ 1,000,000,000
storage_overage = max(0, stored_gb − included_gb) × $0.03
query_overage = max(0, query_hours − included_hours) × $0.30
monthly_estimate = seats + storage_overage + query_overage
Scenario guidance
Model volume changes before choosing a plan
High-volume event
Model request or heartbeat events separately. Sampling, aggregation, and a shorter retention period can change their storage contribution by orders of magnitude.
Wide business event
Measure the serialized payload after redaction. One completion event may be larger than a debug log, but sending fewer events can still cost less.
Query-heavy team
Use aggregate runtime across scheduled reports, dashboards, investigations, and automation. Query count alone does not reveal query-hour usage.
Replace assumptions with measured values
- Sample serialized event sizes by event name.
- Count events after sampling, redaction, and retry deduplication.
- Use actual query-runtime usage from the intended team.
- Model retention separately for high- and low-volume tables.