Metrics and monitoring costs explained: series, cardinality, and retention
Start with a calculator if you need a first-pass estimate, then use this guide to validate the assumptions and catch the billing traps.
Metrics bills are usually a cardinality problem, not a "how many hosts do we have?" problem. This page is the metrics-specific deep dive inside the broader observability cost model. This is the metrics cardinality and monitoring economics page.
Stay here when you already know metrics are the expensive signal family and need to fix series growth, labels, dashboards, or alert pressure. Go back to the observability parent page if the broader signal split is still unclear.
When this page should be your main guide
- You need to understand why series count grows faster than host or service count.
- You suspect label choices, dashboards, or alert rules are multiplying cost silently.
- You already know metrics are the problem and want a narrower workflow than the full observability guide.
If the bigger question is "logs vs metrics vs traces, which signal family is driving the bill?", start with observability costs first rather than treating this page as a full observability overview.
1) Build the series count correctly
- Series count = metrics x label combinations x environments x cluster or region spread.
- Cardinality is the multiplier: one new high-uniqueness label can create thousands of series.
- Churn matters too: short-lived pods, dynamic paths, and ephemeral tenants can create noisy growth.
- Tool: Metrics time series cost
A common mistake is counting metric names but not the combinations behind them. Ten metrics with ten environments and fifty route labels are not "ten metrics"; they are hundreds or thousands of billable series.
2) The label patterns that usually create runaway cost
- Request-level IDs: requestId, traceId, userId, sessionId, full URL path.
- Ephemeral infrastructure: pod name, task ID, autoscaled instance names.
- Unbounded tenant dimensions: raw customer IDs instead of tier or segment buckets.
- Copy-paste instrumentation: metrics duplicated across services with slightly different label sets.
The safest pattern is to label metrics with values that stay useful in dashboards and alerts: route template, status family, service, region, environment, or tenant tier. If a label is too unique to aggregate meaningfully, it is usually too unique to belong on a metric.
3) Resolution, retention, dashboards, and alerts
- Resolution: higher-frequency collection creates more samples and more query load.
- Retention: longer retention increases stored footprint and keeps expensive data around longer.
- Dashboards: frequently refreshed boards or API polling can generate recurring query charges.
- Alerts: alert count, evaluation frequency, and high-resolution alarms can add a second bill.
Not every metric needs one-second resolution or long retention. Reserve the expensive settings for the signals that truly support incident response, SLO tracking, or customer-visible performance.
4) A practical metrics review workflow
- List the top metric families by active series count.
- Identify which labels create the multiplication.
- Cut or bucket the labels that do not improve alerting or decision-making.
- Review dashboard refresh rates and query ranges for high-volume boards.
- Shorten retention or reduce resolution for signals that are rarely used after incident windows.
5) Prioritize fixes by risk and savings
- First: stop the worst high-cardinality labels from generating new series.
- Second: remove duplicate custom metrics or collapse them into fewer dimensions.
- Third: trim refresh-heavy dashboards and overly frequent alert evaluations.
- Fourth: move rarely used long-tail metrics to lower frequency or shorter retention.
The fastest safe savings usually come from label hygiene, not from turning off whole dashboards blindly. Reduce cost in the order that preserves operator confidence.
Worked review checklist
- What are the top ten metric families by active series count?
- Which labels are unbounded or effectively unique?
- Which alerts truly need high resolution?
- Which dashboards refresh constantly but are rarely used in incidents?
- Which metrics could be logs or traces instead of high-cardinality metrics?
Related tools
When to move to provider-specific pricing pages
Once you understand your series count and governance problem, move to provider-specific pricing when you need product details such as CloudWatch custom metrics, alarm pricing, Azure Monitor charge boundaries, or Google Cloud monitoring tiers. This page should help you arrive there with cleaner assumptions.