Google Cloud Platform Observability enhancements now GA

Monitoring Google Cloud at enterprise scale involves more than collecting a fixed set of metrics. Customers using our existing Google Cloud integration have told us platform teams need broader metric coverage that keeps pace with Google Cloud, an authorization model that meets current IAM requirements, a way to configure monitoring consistently across many projects, and faster access to data for time-sensitive workloads. When those pieces are handled separately, onboarding slows down and incident investigation moves across multiple tools.

Today, July 31, 2026, we’re announcing the general availability of new capabilities for Google Cloud Platform Observability (GCPO) in New Relic to address each of those needs. Explore Google Cloud Platform Observability to see how GCPO supports secure onboarding, broader Google Cloud metric visibility, faster polling option, and cloud-to-application troubleshooting in one platform.

This release introduces a modernized foundation for Google Cloud monitoring in New Relic. It uses Workload Identity Federation for keyless authorization, supports Terraform-based deployment at scale, and collects dimensional metrics with native Google Cloud labels for supported services, and 1-minute polling option (as limited preview) for select services. That telemetry can be used with New Relic entity context, dashboards, alerts, and APM data to investigate whether infrastructure behavior is affecting an application or service.

Use keyless authentication for Google Cloud Monitoring

Long-lived service account keys can create friction for teams operating under strict credential-management policies. Security teams increasingly prefer short-lived, identity-based access because it reduces the need to distribute and rotate static credentials.

GCPO now supports Workload Identity Federation (WIF), allowing New Relic to obtain short-lived tokens rather than requiring customers to share long-lived static service account keys for the integration. This gives platform and security teams an authorization approach that is better aligned with modern Google Cloud IAM practices.

For a platform engineer onboarding multiple projects, this means the monitoring design can start with an identity-based trust relationship instead of a workflow built around static key files. Security and IAM administrators fully control the identity pool and permissions granted to the integration, while observability teams get a clearer path to deployment.

Deploy consistently across projects with Terraform

Manual setup becomes difficult to maintain when an organization monitors tens or hundreds of Google Cloud projects. Differences in project configuration, labels, and permissions can make coverage inconsistent and complicate troubleshooting later.

GCPO supports Terraform-based configuration so teams can define monitoring setup as code and apply it through their existing deployment workflows. Teams can also grant permissions at the folder level to bring all projects in the folder into monitoring with a single trust setup. A repeatable configuration helps platform teams standardize how projects connect to New Relic, review changes before deployment, and reproduce the setup as their Google Cloud footprint grows.

WIF and Terraform address different parts of the same onboarding problem: WIF provides the authorization model, while Terraform provides a scalable and repeatable deployment method. Together, they help reduce the one-off work involved in adding monitoring to across projects.

Explore dimensional metrics and native Google Cloud labels

Google Cloud services and their metrics change over time. A monitoring integration that depends on manually mapped event structures can require additional engineering work before newly available metrics appear in customer workflows.

GCPO now collects all GA and Beta metrics as industry standard dimensional metrics for supported services from Google Cloud Monitoring. Dimensional metrics preserve attributes that teams can use to filter, facet, query, and compare data in New Relic. Native Google Cloud labels are also available as queryable dimensions, providing useful context such as project, region, resource, environment, or other labels associated with the metric.

For example, an SRE investigating increased latency can compare a metric across projects or regions, then use the available labels to narrow the investigation to the affected resources. The same context can help teams build dashboards and alerts that reflect how their Google Cloud environment is organized.

At GA, the first phase includes 31 services with Entity Support and four services with Metrics-Only Support. Services with Entity Support can provide New Relic entity experiences such as Entity Explorer visibility, relationship context, curated dashboards, and integrated alerts. Metrics-Only Support makes dimensional metrics available without the complete entity experience.

Reduce alerting latency with 1-minute polling (Limited Preview)

Some Google Cloud workloads such as customer-facing services, streaming pipelines, and database performance monitoring, benefit from shorter observation intervals. Longer polling intervals can delay incident detection during time-sensitive events.

As part of this release, GCPO now supports 1-minute polling for select Google Cloud services as a Limited Preview, available to approved customers. This reduces the observation gap compared with the default 5-minute polling used across our cloud integrations. Contact your New Relic account team to join the Limited Preview. 

Connect Google Cloud health to application performance

Cloud-native monitoring can show that a Google Cloud service is under pressure, while application monitoring can show that response time or error rate is changing. During an incident, teams still need to determine whether those signals are related.

GCPO brings Google Cloud infrastructure telemetry into the same New Relic platform used for APM and broader full-stack observability. Metrics, labels, entity metadata, dashboards, and alerts provide infrastructure context that teams can compare with application and service behavior.

Consider an application that begins returning errors after latency increases in a dependent Google Cloud service. An SRE can start from the affected application or service, review the related Google Cloud telemetry, and use project, region, and resource context to narrow the scope of the problem. It gives teams correlated evidence in one workflow.

Existing Google Cloud Platform integrations continue to coexist with new ones

Customers already using an existing New Relic Google Cloud integration are not required to migrate as part of this GA release. Existing and new integrations coexist, and your current setup continues to work exactly as it does today. No immediate action is required.

For new Google Cloud monitoring projects, we recommend the new integration take advantage of WIF, Terraform-supported deployment, dimensional metrics, and the expanded list of supported services. Existing customers should review the final setup and supported-service documentation before deciding how to introduce new WIF based integrations into their environments.

Get started

Before configuring GCPO, coordinate with your Google Cloud platform and IAM teams to identify:

• The Google Cloud projects and services you want to monitor.
• The IAM permissions and WIF trust configuration required for the integration.
• The Terraform workflow and ownership model used to deploy and maintain the configuration.
• The supported services for which you need dimensional metrics, entities, dashboards, or alerts.
• The labels your SRE and platform teams will use to query and organize telemetry.

See the setup documentation (Introduction to Google Cloud Platform integrations) for the full list of prerequisites, supported services, and configuration steps"