Datadog vs Cloud Monitoring - The Boundary for GCP Monitoring

Conclusion - Cloud Monitoring If You Stay Within One Project, Datadog If You Span Across

The conclusion first, as conditions. If your monitoring targets fit within one Google Cloud project, the viewers are a single team, and log search is the main use, Cloud Monitoring and Cloud Logging suffice. Conversely, if any of the following applies - you have multiple projects, you want to follow GKE containers per service, or you want to see them on the same screen as AWS or on-premises - adding Datadog becomes worthwhile. The reason is the difference in design unit. Google Cloud's observability stack determines free tiers and billing per project and billing account, while Datadog determines billing per host and SKU (as of September 2026, Source: Google Cloud Observability pricing). The GCP-specific point that differs from Datadog vs CloudWatch and Datadog vs Azure Monitor is this box called the "project".

GCP Observability Is Built from Three Products and the Unit of the Project

Google Cloud's documentation lists Cloud Logging / Cloud Monitoring / Cloud Trace alongside Error Reporting and Cloud Profiler as its observability product group, and describes Cloud Monitoring as a tool that collects metric data and lets you monitor and visualize the performance of applications and services (as of September 2026, Source: Cloud Monitoring documentation). The guidance on the same page is to distribute the Ops Agent to Compute Engine VMs and to collect from on-premises and hybrid environments with BindPlane. Viewing metrics from multiple projects in one place requires a separate configuration of a "metrics scope", and this is the first place that makes you aware of the "project box". Log search and metric visualization start without an additional contract, while designs that cross boxes are something you assemble yourself; that is the character of the GCP standard.

Where the Billing Units Differ

The billing unit is the volume ingested for Google Cloud and the number of targets for Datadog. On Google Cloud's pricing page (as of September 2026), Cloud Logging is a unit price per GiB ingested, with 30 days of storage and search included in the unit price and a monthly free tier per project. Cloud Monitoring's standard metrics are not billed, other metrics are a unit price per MiB ingested, and Cloud Trace is a unit price per number of spans (in units of one million). Datadog, as of August 2026, has Infrastructure Monitoring Pro as a monthly amount per host (annual contract), and logs on 2 axes: a unit price per GB ingested and a unit price per number of indexed events (in units of one million) by retention period.

Because the units differ, cheapness is decided by "volume or host count". It is a simple correspondence: in a configuration with a lot of logs and few hosts, ingestion-volume billing weighs more, and in one with many hosts and few logs, host billing weighs more. How SKUs stack up is left to How to Decode the Pricing Structure. This article explains how billing works. For current unit prices and plans, refer to each vendor's official pricing page.

From Where Does Datadog See GCP, and What Do You Pay on the GCP Side?

Datadog's Google Cloud integration reads Cloud Monitoring API metrics through a service account. The official documentation recommends automatic discovery at the organization or folder level, which brings projects created later into scope as well (as of September 2026, Source: Google Cloud Platform). What is easy to overlook is the cost on the GCP side: these reads are subject to Monitoring API read billing (counted by the number of time series returned, with a monthly free tier per billing account) (same date, Source: the same pricing page). By default, this cost and quota accrue to the project the service account belongs to, and switching to per-project attribution requires enablement by Datadog support and an additional role. Logs are forwarded with Pub/Sub and a Dataflow template (same date, Source: Google Cloud Log Forwarding Setup).

Lining Up the Cost Items for the Same GKE Configuration - The Variables That Decide the Cost Advantage

To turn this into formulas, assume N GKE nodes, 100 containers, and a constant daily volume of logs ingested (L GiB per month). Assume metrics are GCP standard metrics only. On the Google Cloud side, metrics are not billed, so the monthly amount is determined solely by "(L minus the project's monthly free tier) x Cloud Logging's ingestion unit price", and the node count N does not appear in the formula. On the Datadog side it is "N x Infrastructure Monitoring Pro unit price + L x log ingestion unit price + number of indexed events x indexing unit price", and because the indexed event count cannot be derived from GB, how much of the ingested logs to index becomes a design decision.

The straightforward reading of this table is that for a log-centric single project, Google Cloud's standard tooling tends to come out lower, and the fewer the nodes and the larger the log volume, the stronger that tilt. Datadog's total opens up widely between a floor (ingestion only) and a ceiling (everything indexed) because the proportion to index can be decided by design, and the exclusion settings of Log Management become the main factor in cost. Conversely, in a configuration with many nodes and few logs, the node count that does not appear in the Google Cloud formula rises as the fixed part on the Datadog side, while the weight of ingestion-volume billing for logs fades. If you choose Datadog, restate the difference between the two formulas as "can it be recovered through the cross-cutting screen and container granularity" and decide on that basis. To get the answer, it is enough to put your own N and L, and the unit prices from each vendor's pricing page, into the formulas.

Where Cloud Monitoring Is Superior

Needing neither an additional contract nor connection settings is the first strength. Google Cloud standard metrics are not billed, Cloud Logging has a monthly free tier per project, ingested logs include 30 days of storage and search in the unit price, and the pricing page states explicitly that there is no additional charge for search and analysis (as of September 2026, Source: Google Cloud Observability pricing). Cloud Trace and uptime checks also have monthly free tiers, so a small system can start observability with a zero bill. The second is cost predictability: the monthly cost can be read from ingested GiB and span count alone without counting hosts. The third is the alignment of box and permissions: per-project observability is closed to the users of that project, and no decision arises about handing service account permissions to an outside party. For a small single project, the choice that does not add this work is rational.

Three Situations Where Datadog Pays Off, and How to Avoid Double Ingestion

Conversely, Datadog's design unit pays off when you cross the box called a project.

If any of the three situations applies, the next step is a design that does not ingest twice. The integration has settings to select the services to collect by namespace and to write include / exclude filters; the official documentation describes these as settings to "optimize Cloud Monitoring API costs" and gives the exclusion of *_cost and *_count as examples (as of September 2026, Source: Google Cloud Platform). Excluding regions and a filter that ingests only hosts labeled datadog:true are on the same screen. If you place the Agent on GKE nodes, fine-grained, low-latency metrics can be collected on the Agent side, so dividing the work so that API-based collection is limited to managed services the Agent cannot reach tightens both the read billing on the GCP side and the host count on the Datadog side.