Why Your Monitoring Bill Grows Faster Than Your Traffic

Here’s a pattern almost every growing engineering team hits. You go from 10 services to 40. Traffic roughly triples. Then the monitoring invoice comes in at five times what it was a year ago.

No one did anything wrong. No one enabled anything crazy. The bill just compounded.

This post walks through why that happens, with real list-price math, and what you can do about it this week whatever tool you use.

The short answer: you’re billed on five meters at once

Most usage-based monitoring vendors don’t charge you for one thing. They charge you on several independent meters, and each one scales with a different property of your system:

Meter	What it scales with	Why it grows faster than traffic
Hosts / nodes	Your infrastructure footprint	Autoscaling peaks, more microservices, sidecars
Log ingestion (per GB)	How chatty your code is	More services means more inter-service logs
Log indexing (per event)	How much you want searchable	Billed on top of ingestion
Custom metrics	Unique metric × tag combinations	Cardinality multiplies; it doesn’t add
Per-product add-ons	Each feature you turn on	APM, RUM, replay and synthetics each have their own SKU

Traffic growth touches all five at the same time. When several meters grow at once and multiply into each other, the total grows faster than any single input.

Let’s do the actual math

Take Datadog as the example, because it’s the most common and its list pricing is public. At the time of writing, annual-commit list prices are roughly:

• Infrastructure (Pro): $15 per host per month, including 100 custom metrics per host
• APM: $31 per host per month
• Log ingestion: $0.10 per GB
• Log indexing (15-day retention): $1.70 per million events
• Custom metrics overage: about $5 per 100 metrics per month

Note: These are public list prices. Negotiated contracts differ, and vendors change pricing. Always check the current pricing page. The point here isn’t the exact dollar figure but the shape of the curve.

For the log math we assume about 2 million log events per GB (an average event size of roughly 500 bytes), with half of all logs indexed.

Year 1: 10 services, 12 hosts

Line item	Calculation	Monthly
Infrastructure	12 hosts × $15	$180
APM	12 hosts × $31	$372
Log ingestion	30 GB/day × 30 days × $0.10	$90
Log indexing	Half of logs indexed ≈ 900M events × $1.70/M	$1,530
Custom metrics	3,000 active − 1,200 included = 1,800 × $0.05	$90
Total		≈ $2,262 / month (~$27K / year)

Year 2: 40 services, 40 hosts

The team splits the monolith further, adds a few AI-powered features, and autoscaling now peaks at 40 nodes.

Line item	Calculation	Monthly
Infrastructure	40 hosts × $15	$600
APM	40 hosts × $31	$1,240
Log ingestion	150 GB/day × 30 days × $0.10	$450
Log indexing	Half indexed ≈ 4,500M events × $1.70/M	$7,650
Custom metrics	25,000 active − 4,000 included = 21,000 × $0.05	$1,050
Total		≈ $10,990 / month (~$132K / year)

Services grew 4x. Hosts grew 3.3x. The bill grew 4.9x.

And this is the conservative version. It doesn’t include RUM, session replay, synthetics, security monitoring, or the separate error-tracking and product-analytics tools most teams pay for on the side.

Where the compounding really comes from

1. Logs are billed twice

Ingestion and indexing are separate charges. In the example above, indexing is 70% of the Year 2 bill. Teams are usually surprised by this, because ingestion is the number they see on the pricing page.

The trap is that every new service adds its own logs plus logs about talking to other services: request logs, retry logs, client-library debug output. Log volume tends to grow faster than service count.

2. Cardinality multiplies

A “custom metric” usually isn’t one metric. It’s every unique combination of a metric name and its tag values.

Take one innocent histogram:

http_request_duration_seconds
  tags: endpoint (50) × status_code (5) × pod (20) × region (2)

That’s 50 × 5 × 20 × 2 = 10,000 billable series from one line of instrumentation. Add a customer_id tag “just for debugging” and you’ve multiplied it again by however many customers you have.

On per-metric pricing models, metrics sent through OpenTelemetry are typically counted as custom metrics too. Moving to open standards doesn’t avoid this meter.

3. Host counting follows your peaks, not your average

Autoscaling is great for your cloud bill and bad for host-based licensing. Many vendors bill on a high-water-mark or near-peak count of hosts across the month. One traffic spike that scales you from 20 to 40 nodes for a few hours can bill as 40 hosts for the month.

4. Every feature is its own SKU

APM, profiling, RUM, session replay, synthetics, database monitoring, security: each is priced separately, often with its own unit. Turning one on for a single investigation and forgetting to turn it off is one of the most common causes of a surprise invoice.

5. Tool sprawl adds another layer

Most teams don’t run one tool. They run a metrics/APM vendor, a separate error tracker, a session replay tool, and a product analytics tool. That’s four contracts, four pricing models, and four meters, each growing independently.

A checklist to cut your bill this week

You can do all of this without changing vendors.

Logs

• Turn off DEBUG in production. A single service at DEBUG can produce several GB per day on its own.
• Add exclusion filters for health checks, readiness probes, and successful 200 access logs before indexing.
• Index only what you actually search. Archive the rest to cheap object storage you can rehydrate if needed.
• Set retention tiers: 7 days for chatty logs, longer only for audit or security logs.

Metrics

• Pull your top 20 metrics by cardinality. In almost every account, a handful cause most of the cost.
• Remove unbounded tags: user_id, request_id, session_id, full URLs with IDs in the path.
• Replace per-pod tags with per-deployment tags unless you really debug at pod level.

Traces

• Use sampling: keep 100% of errors and slow requests, and a small percentage of healthy ones. Tail-based sampling in an OpenTelemetry Collector does this well.
• Drop spans from noisy internal calls (cache hits, health checks).

Architecture

• Put an OpenTelemetry Collector between your apps and any vendor. It becomes your control point for filtering, sampling, and scrubbing, and it makes switching backends a config change instead of a re-instrumentation project. (Our OpenTelemetry setup guide for Next.js and Node.js walks through it.)
• List every monitoring-adjacent tool you pay for and what each one costs. Overlap is usually larger than anyone thinks.

The deeper fix: change what you’re billed on

The checklist helps, but it has a cost of its own. Every filter you add is data you won’t have during the next incident. Teams end up rationing telemetry to protect the budget, and then struggle to debug because the context they needed was sampled away.

The structural problem is that the price is tied to data volume, and data volume is exactly what grows as you succeed.

There’s another model: pay for the software, and run the data on your own cloud at your own cloud’s storage and compute rates.

That’s how Modulis works:

• It runs in your cloud (BYOC). Logs, traces, metrics, errors, and session replays are stored in your own environment, so you pay your cloud provider’s raw storage and compute rates with no vendor markup per GB.
• It’s billed per application, not per host, GB, event, or metric. Ingestion is unlimited under fair use on every paid plan.
• It’s one deployment, not four tools. Logs, traces, metrics, error monitoring, session replay, and product analytics live together, so you’re not paying four vendors to store the same incident four times.

Plans run from Free to Starter ($199/mo), Growth ($999/mo), and Enterprise (custom pricing). Your cloud infrastructure cost sits on your own cloud bill, and it grows at cloud rates, not vendor rates. See the full breakdown on our pricing page.

Back to the example: when that team goes from 10 services to 40, the subscription line doesn’t move. The bill stops being a negotiation every renewal.

The one question to ask at your next renewal

Before your next contract conversation, ask your team:

“If we doubled our services next year, what would this bill be?”

If no one can answer confidently, or the answer is “we’d have to cut what we collect,” the pricing model is working against your growth.

---

Want to see what your stack would cost on a flat model? Start free or book a 20-minute walkthrough. Bring last month’s invoice and we’ll do the math together.