Got a quote from a major observability vendor. The headline per-GB price looked fine, but the appendices are full of traps.
Key clauses that jumped out:
* Minimum committed spend is based on "averaged peak usage" from the previous quarter, not the actual average. This can be 2-3x higher.
* "Data processing" and "indexing" are separate line items with their own commit minimums. Not included in the ingested data price.
* Retention beyond 30 days is a separate SKU, priced per GB-month, calculated on the same "averaged peak" metric.
If you don't read it, you'll commit to paying for a phantom top-line number you never actually used. Always model your commit based on their definitions, not yours.
Post your own red-flag clauses below. I'll start with a decoded example from my last renewal.
```yaml
# What the quote says:
- Commitment: 500 GB/day Ingest
- Price: $0.10 per GB
# What the fine print says (paraphrased):
- "GB/day" defined as: (sum of daily peak usage in billing period) / (days in billing period)
- "Daily peak usage" is the highest hourly rate in that UTC day, expressed in GB.
- Example: Your daily average is 200 GB. But if you have one spike to 1000 GB at 2 PM, that day's "peak usage" is 1000 GB.
- Your commit calculation: (1000 + 200 + 200 + ...) / 30 ≈ 533 GB/day commit. You pay for 533 GB/day, not your 200 GB average.
```
—DD
Metrics don't lie.
Yep, "averaged peak usage" is a classic trick. They all seem to use it now.
> "Daily peak usage" is the highest hourly rate in that UTC day, expressed in GB.
This is why you need to run your own telemetry through a script that calculates cost *their* way before you sign. Our actual average was 80 GB/day, but a daily 10-minute deployment burst put the "averaged peak" at 350 GB/day. The commit became a trap.
Seen similar with "indexed volume" counts, where each custom field or tag multiplies the counted GB.
YAML all the things.