Many engineers treat vendor pricing pages as opaque marketing artifacts, but they are actually structured documents that can be decoded with a systematic approach. The goal is to extract the key variables and constraints that will determine your actual bill, moving beyond the headline "starts at" figure. A failure to do this often results in budget overruns by the second or third renewal, when usage patterns have solidified.
The first step is to identify the **primary unit of consumption**. This is the metric the vendor uses to meter your usage and charge you. It is rarely as simple as "per user." You must catalog all potential units. For example:
* **Per Host/Node/Instance:** Common for infrastructure monitoring. Clarify if this is physical, virtual, container, or a normalized unit (e.g., vCPU/GB RAM bundles).
* **Per GB Ingested:** Common for logs (Loki, Datadog Logs) or traces (Tempo, Jaeger). Critically, determine what is counted: compressed vs. uncompressed, indexed vs. archived, before or after parsing/dropping.
* **Per Million Time Series or Samples:** Core to metrics platforms (Prometheus, M3DB). Understand the cardinality implications and how ephemeral series are counted.
* **Per Million Spans or Events:** For distributed tracing or event pipelines.
* **Per Seat:** For user-facing analytics or dashboards. Define "active user" precisely.
Once the unit is identified, you must map your **current and projected volumes** to it. This requires data from your own observability stack. For instance, to estimate log ingestion costs, you would not guess; you would measure.
```bash
# Example: Estimate daily log volume from Loki for a 30-day period
loki_volume_query='
sum by (compliance) (
rate(logcli_query_total{compliance="realized"}[30d])
)
# This provides the ingestion rate. Combine with average line size.
```
The second critical layer is **tiering and packaging**. Vendors use tiers to create price breaks, but they also use them to gate features. Your checklist should include:
* Does the price per unit decrease at higher volumes (graduated tiers), or is the rate fixed within a band (volume tiers)?
* Are essential features like retention, SSO, or advanced alerts only available in "Enterprise" or "Pro" packages? This can double the effective cost.
* What is the commitment period? Monthly, annual, or multi-year? Annual commitments typically offer 15-25% discount but reduce flexibility.
* Is there a minimum spend or minimum unit commitment? A "starts at $50/month" often implies a 5-host minimum.
Finally, scrutinize the **ancillary costs and limits**. These are the line items that appear on the quote but not the public page.
* **Data Retention:** Is there a cost for extended retention (e.g., beyond 15 days)? What is the cost gradient for warm vs. cold storage?
* **Egress Fees:** Are there charges for querying your data out, or for exporting it via API?
* **Support SLA:** Is 24/7 phone support included, or is it an add-on costing 20% of the base license?
* **Deployment Model:** Is the price quoted for SaaS, or is there a steep premium for a private/VPC deployment?
By treating the pricing page as a configuration file—parsing its keys, values, and conditional logic—you transform a sales conversation into a technical evaluation. You can then model scenarios (e.g., 20% monthly growth, a new product launch) to forecast spend under different architectures. Always request a formal quote based on your specific volumes; the public page is only the schema.
Regards,
Luke
Measure everything.