If you're reading this, you're probably in one of two situations: comparing observability platforms and trying to figure out what Datadog pricing will mean for your team, or you just opened an invoice that came in higher than expected. Both come back to the same problem: Datadog's pricing model has a lot of moving parts, and it's easy to underestimate how they add up.

This isn't a sales pitch. It's a straight breakdown of how Datadog actually charges, where costs tend to grow past the sticker price, and how to estimate what you'll really pay before you sign anything. By the end, you'll know which parts of your usage drive the bill and what to ask before committing to an annual plan.

How Datadog's pricing model works

Datadog doesn't charge one price for its platform. It charges separately for each product you turn on, and each product has its own pricing unit:

  • Infrastructure monitoring and APM are priced per host.
  • Log management is priced by data volume.
  • Custom metrics are usage-based, with additional charges when you exceed your included allotment.
  • Security products and synthetic monitoring are billed by resource or by test run.

Each of these units comes with its own included allotment and overage threshold. That's manageable when you're running one product. It gets harder to track once infrastructure monitoring, APM, and log management are running together, because each one is metering something different and hitting its ceiling at a different time. The bill isn't one number. It's several separate charges that stack up as you add more of the platform.

This modular structure is also why teams end up buying more than they planned to:

  • APM costs less per host when infrastructure monitoring is already active on that host; buying APM on its own, without infrastructure monitoring, costs more per host.
  • Security and synthetic monitoring follow the same pattern: separate line items, not folded into what you already pay for.

None of this is hidden. It's just spread across enough separate products and pricing units that the total is easy to lose track of.

Ultimately, two things determine how fast your Datadog bill grows: how many products you turn on, and how close usage runs to each one's included allotment. A team running infrastructure monitoring alone has a predictable bill. A team running infrastructure monitoring, APM, log management, and custom metrics together is managing four separate meters at once, and that's where forecasting gets genuinely difficult.

What each Datadog product costs

Since the model is genuinely per-product, here's a plain rundown of what each major product bills on, grouped by category. Exact rates change, so check Datadog's pricing page for current numbers.

APM and tracing

Datadog application performance monitoring, or APM, is priced per APM host, per month, across three tiers: APM, APM Pro, and APM Enterprise.

  • APM: Covers distributed tracing and service health metrics.
  • APM Pro: Adds data streams monitoring, which tracks Kafka and RabbitMQ pipelines.
  • APM Enterprise: Adds the continuous profiler, which captures code-level performance data (CPU, memory, I/O).

Tracing adds two more things to watch: ingestion and indexing. Datadog's APM billing documentation shows that each APM host includes an allotment for both. APM ingestion measures the volume of trace data flowing in, including ingested spans submitted through OpenTelemetry. Indexed spans are the traces you retain and make searchable. Database monitoring and network monitoring are priced separately again, each per host.

Infrastructure and logs

Infrastructure monitoring is priced per host, while log management costs depend on how much data you ingest and keep searchable.

Infrastructure monitoring has its own Infrastructure Pro and Infrastructure Enterprise tiers, each with a different container allotment per host; container monitoring beyond that allotment is billed separately.

Log management then has a few separate meters:

  • Log ingestion: The data you send to Datadog.
  • Standard indexing: The indexed logs you keep searchable for real-time monitoring and alerting.
  • Flex Logs: Lower-cost storage for high-volume or long-term logs that don't need the same real-time monitoring and alerting capabilities.

Retention filters let you control which logs get the more expensive standard indexing treatment and which get the cheaper Flex Logs treatment, giving you a lever for controlling log costs. That's worth paying attention to: 70% of DevOps leaders surveyed by Sawmills named high log ingestion and indexing among the top contributors to rising observability spend.

New Relic's infrastructure monitoring and log management price the same way, with no ingest-versus-index split to track.

Digital experience monitoring

Real user monitoring (RUM) is priced by session, while synthetic monitoring is priced per test run.

Datadog offers RUM Measure and RUM without Limits, with session replay available as a separate per-session add-on.

Datadog RUM pricing showing RUM Measure, RUM Investigate and Session Replay priced per 1,000 sessions

Annual billing unlocks volume discounts across nearly every product on this list, and those discounts are real. The catch is that they only apply up to the volume you committed to. Usage beyond that commitment can be charged at higher on-demand rates, which is a common source of budget surprises and one of the more common observability pricing traps to account for when comparing vendors.

Estimating your own Datadog cost

You can get a reasonable estimate before you sign anything, using the same units Datadog bills on:

  1. Count your hosts. Count how many hosts, VMs, or container-heavy nodes will run infrastructure monitoring and APM, and check your average container density per host against Datadog's included allotment.
  2. Estimate log volume. Separate what needs to be ingested and scanned from what actually needs to be indexed and kept searchable. Not every log needs 30 days of searchable retention. Being selective here is one of the biggest cost levers available to you.
  3. Account for custom metrics. If your team tags metrics liberally today, that habit will carry into your Datadog usage and can push you past included allotments faster than expected.

Once you have those three numbers, map them against Datadog's published pricing.

Build one estimate for your usage today and another for twelve months from now, factoring in planned changes such as new services, a Kubernetes migration, or longer log retention. Then layer any security or synthetic monitoring add-ons on top.

Still deciding what belongs in that baseline? Your choice of infrastructure monitoring tools will depend on factors such as your stack, integrations, and monitoring requirements.

Existing Datadog customers can start with the Plan & Usage page rather than rebuilding the estimate from scratch. It shows real-time usage metrics against your current commitment. Cost monitors and anomaly detection can also flag changes in usage metrics such as custom metric count or log volume before they become an overage.

What to ask before signing an annual commitment

A few direct questions to a sales rep, asked before you sign, can save a lot of budget friction later.

  • How are overages billed? Ask whether overage charges apply per product or roll up across your account, and whether they're billed monthly or trued up at renewal.
  • Does the commitment lock in a specific SKU mix? Some annual contracts commit you to a particular combination of products and volumes. If your usage shifts (say, fewer logs but more hosts), find out whether you can rebalance the commitment or end up paying for both.
  • How does the contract handle usage spikes? Ask what happens during a traffic spike or a one-time migration project that temporarily increases usage. Find out whether that extra usage falls within your existing commitment or triggers on-demand charges.
  • What's the true-up process at renewal? Ask whether overage volume gets settled monthly, quarterly, or all at once at renewal. Knowing the schedule in advance makes it easier to avoid a large, unexpected true-up bill.
  • Who signs off internally before usage grows? Ask your own team this one, not the vendor. If adding a custom metric or turning on a new product doesn't require approval, usage and cost can grow faster than anyone expects. A lightweight check, even a quick Slack message before enabling something new, prevents a lot of that drift.

Getting these answers in writing before signing can do more for cost predictability than focusing on the sticker-price discount alone.

A different way to think about observability pricing

Sticker price gets most of the attention when you're comparing platforms, but predictability matters just as much once you're running more than one product across a growing environment. A slightly higher entry price with two pricing dimensions is often easier to budget than a lower entry price with ten.

New Relic takes a simpler approach. Its standard user-based pricing model centers on two core metrics:

  • Data ingest: The volume of telemetry data you send to New Relic, including metrics, events, logs, and traces.
  • Users: The people who need access to the platform. Basic users are free, while other user types are priced according to their level of access.

That means you don't have to count hosts or buy a separate SKU for core capabilities such as infrastructure monitoring, APM, logs, or containers. New Relic includes unlimited hosts and access to 50+ capabilities, although optional add-ons such as Advanced Compute can add to the cost. 

현재 이 페이지는 영어로만 제공됩니다.