New Relic EU Alternative: CLOUD Act Still Applies to US Observability Platforms — What EU Developers Use Instead

Post #886 in the sota.io EU Cyber Compliance Series

New Relic is one of the most widely deployed observability platforms in the world. It offers EU-region data ingestion, a GDPR-compliant data processing addendum, and Standard Contractual Clauses (SCCs) covering data transfers. For many EU development teams, that combination looks sufficient.

It is not. The structural problem is not New Relic's GDPR paperwork — it is New Relic's corporate structure. New Relic is a US company, majority-owned by Francisco Partners and TPG Capital, both US-based private equity firms. As a US company, New Relic is subject to the US CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 18 U.S.C. § 2713), which requires US-incorporated companies to produce data stored anywhere in the world when presented with a valid US law enforcement order — regardless of whether the data sits in EU servers.

SCCs, DPAs, and GDPR Article 46 transfer mechanisms address the question of EU-to-US data transfers. They do not address CLOUD Act compelled disclosure. These are two different legal instruments, and the confusion between them is the source of most misplaced confidence in US observability platforms with EU regions.

This guide explains what observability data is GDPR-relevant, why CLOUD Act compelled disclosure is structurally distinct from transfer compliance, and which EU-native observability alternatives solve the problem at the root.

What Observability Data Is GDPR-Relevant

Developers often assume that observability data — metrics, traces, logs — is not personal data under GDPR. This is frequently wrong, and the error matters because New Relic's data residency offering does not protect you from CLOUD Act disclosure of GDPR-relevant data.

GDPR Article 4(1) defines personal data as "any information relating to an identified or identifiable natural person." Under EDPB guidance and consistent DPA enforcement, the following categories of observability data routinely qualify:

Application traces and spans. Distributed tracing captures the path of a request through your system. When that request includes a user action, the trace payload often contains user identifiers, session tokens, or email addresses — directly in span attributes, or in request parameters that your instrumentation captures. New Relic APM traces HTTP request URLs and headers by default. If those URLs include /api/users/user@example.com or ?user_id=12345, the trace data is personal data.

Error messages and stack traces. New Relic Errors Inbox captures exception messages and stack traces. Exception messages frequently include values that triggered the error — email addresses from failed validation, user IDs from failed authorization checks, customer names from failed billing operations. If your application throws IllegalArgumentException: invalid email format for user@example.com, that string is stored in New Relic.

Log ingestion. New Relic Logs captures application log output. If your application logs user activity (login events, purchase completions, API access), user-identifiable information will appear in your New Relic logs. Even "application logs" that do not explicitly contain PII often contain session tokens or device fingerprints that qualify under GDPR recital 30.

Browser monitoring. New Relic Browser captures end-user interaction data including IP addresses, browser identifiers, and JavaScript error context. IP addresses are personal data under GDPR Article 4(1) and Recital 30 in the EU context.

Custom attributes. New Relic APM allows developers to attach custom attributes to transactions. Teams frequently attach user context — subscription tier, user ID, account region — to make their dashboards more useful. All of that becomes personal data in New Relic.

The threshold for GDPR applicability is lower than most developers expect. You do not need to be deliberately storing PII in your observability platform for your observability data to be personal data. Inadvertent capture through request URLs, error messages, and log output is sufficient.

CLOUD Act Compelled Disclosure: Why SCCs Do Not Help

When EU DPAs evaluate New Relic's transfer compliance, they examine whether New Relic has Standard Contractual Clauses in place, whether its transfer impact assessment addresses the risks of US intelligence access, and whether New Relic's DPA commits to adequate safeguards. New Relic has all of these.

The CLOUD Act problem is a different question, and it operates on a different legal plane.

CLOUD Act 18 U.S.C. § 2713 requires US companies to "preserve, backup, or disclose the contents of a wire or electronic communication and any record or other information pertaining to a customer or subscriber." This obligation applies regardless of where the data is stored. A New Relic engineer in San Francisco, a New Relic data center in Frankfurt, and New Relic's EU subsidiary are all potentially reachable through a single US law enforcement order directed at New Relic Inc.

SCCs govern transfers from your organisation to New Relic. They do not govern what New Relic must do when US law enforcement demands access to data New Relic already holds. The SCC mechanism creates contractual obligations between you and New Relic — it does not change New Relic's legal obligations under US domestic law.

GDPR Article 48 addresses this directly: "Any judgment of a court or tribunal and any decision of an administrative authority of a third country requiring a controller or processor to transfer or disclose personal data may only be recognised or enforceable in any manner if based on an international agreement, such as a mutual legal assistance treaty." This means New Relic should not comply with a CLOUD Act order without legal review. It does not mean New Relic cannot comply with a CLOUD Act order. The EU-US Data Privacy Framework (DPF) does not contain a mutual legal assistance treaty provision that neutralises CLOUD Act compelled disclosure.

The practical risk for EU developers is specific: if New Relic receives a CLOUD Act demand for data related to your application's users — because your US customer is party to a US legal proceeding, or because a US regulatory body is investigating a US-incorporated company whose EU subsidiary uses your platform — New Relic may be required to produce that data. You will not be notified in advance. The disclosure may involve personal data of EU data subjects. This is a GDPR exposure.

The DPA of Bavaria (BayLfD) addressed this scenario in its 2022 opinion on US cloud service providers, concluding that CLOUD Act exposure cannot be fully mitigated through contractual safeguards alone where the service provider is a US-incorporated entity. The DPA of Berlin reached a similar conclusion. The Schrems II ruling and its aftermath have not changed the structural analysis.

New Relic's Corporate Structure

Understanding why New Relic's EU data center does not solve the CLOUD Act problem requires a brief review of its corporate structure.

New Relic, Inc. was taken private in 2023 by Francisco Partners and TPG Capital in a transaction valued at approximately $6.5 billion. Francisco Partners is headquartered in San Francisco, California. TPG Capital is headquartered in Fort Worth, Texas. New Relic, Inc. remains a Delaware-incorporated US company with its principal executive offices in San Francisco.

New Relic's European operations are conducted through subsidiaries (including New Relic Ireland Limited for EU/EEA data processing). However, CLOUD Act obligations run to the US parent. The existence of an EU subsidiary does not shield the parent from CLOUD Act compelled disclosure requirements, and the parent controls the infrastructure and access systems through which CLOUD Act compliance would be executed.

This is structurally identical to the situation with AWS (US parent, EU region, CLOUD Act applies), Microsoft Azure (US parent, EU region, CLOUD Act applies), and Datadog (US parent, EU region, CLOUD Act applies). The geographic location of your data is not the determining factor. The corporate nationality of your infrastructure provider is.

EU-Native Observability Alternatives

The following alternatives are EU-native in the sense that matters for CLOUD Act: no US parent company, or self-hosted deployment that eliminates the third-party data controller relationship entirely.

Grafana LGTM Stack (self-hosted or EU-native cloud)

Grafana Labs is headquartered in New York and is a US company — Grafana Cloud has the same CLOUD Act exposure as New Relic. However, the LGTM stack (Loki, Tempo, Mimir, Grafana) is open source and can be self-hosted entirely on EU infrastructure under your control. When self-hosted, there is no third-party data controller: your observability data stays in your own infrastructure and is subject only to your own legal obligations.

The LGTM stack provides full feature parity with New Relic for most use cases: Grafana for dashboards and alerting, Loki for log aggregation, Tempo for distributed tracing, and Mimir (or Prometheus) for metrics. Grafana's query language (LogQL, TraceQL, PromQL) is mature and well-documented.

Operational overhead is the trade-off. Self-hosted LGTM requires capacity planning, storage configuration, retention policy management, and upgrade cycles. For teams with dedicated platform engineering capacity, this is manageable. For smaller teams, managed EU-hosted options may be preferable.

Managed options: Hetzner Cloud, Scaleway, and OVHcloud all offer VM environments where you can run LGTM on EU-jurisdiction infrastructure under your control. Grafana Labs also offers regional hosting partnerships in the EU, but the Grafana Labs SaaS offering (Grafana Cloud) retains US parent CLOUD Act exposure.

SigNoz (open source, self-hosted)

SigNoz is an open source observability platform built on OpenTelemetry. It provides metrics, traces, and logs in a unified interface — similar to New Relic's full-stack observability model. SigNoz is developed by SigNoz Inc., a US entity, but the software is Apache 2.0 licensed and can be self-hosted entirely.

When self-hosted on EU infrastructure (Hetzner, Scaleway, IONOS, OVHcloud), SigNoz data stays under your control with no CLOUD Act exposure. SigNoz uses ClickHouse as its storage backend, which handles high-volume trace and log ingestion efficiently.

SigNoz's differentiation relative to LGTM: unified data model (no separate tools for logs vs traces vs metrics), newer codebase with less operational complexity, native OpenTelemetry support with no proprietary agent required. The trade-off is a smaller community and fewer integrations than the Grafana ecosystem.

Elastic APM (EU-hosted Elastic Cloud)

Elastic N.V. is incorporated in the Netherlands. Elastic Cloud for EU customers uses infrastructure that can be provisioned on EU providers. EU Elastic N.V. as the contracting entity means the EU subsidiary — not Elastic US — is the data controller for EU customer data.

The CLOUD Act analysis here is more nuanced than for New Relic or Datadog. Elastic N.V. is Dutch. CLOUD Act jurisdiction runs to US companies. Whether CLOUD Act applies to data held by a Dutch subsidiary of a US-origin company depends on operational control and data access structures. Elastic has argued, and EU DPAs have provisionally accepted, that EU customer data in EU Elastic Cloud is controlled by the EU entity with appropriate separation.

For teams that need a managed service with EU-native contractual structure, Elastic Cloud with EU as contracting entity is the strongest candidate in the managed observability space. Elastic APM, Elastic Logs, and Elastic Infrastructure Monitoring cover the full New Relic APM feature set.

Pricing: Elastic Cloud is consumption-based. For equivalent New Relic usage, Elastic Cloud typically costs 20-40% less at comparable data volumes.

VictoriaMetrics (metrics-focused, self-hosted)

For teams whose primary observability need is metrics and alerting (rather than full APM traces and logs), VictoriaMetrics is the highest-performance EU-deployable option. VictoriaMetrics GmbH is a German company (registered in Munich). VictoriaMetrics Enterprise is available with commercial support from a German entity.

VictoriaMetrics is PromQL-compatible and operates as a drop-in replacement for Prometheus at large scale. It has significantly lower resource requirements than Prometheus and built-in clustering for high availability. It does not provide native distributed tracing or log aggregation — those require integration with Tempo/Loki or similar.

Checkmk (EU-originated monitoring)

Checkmk GmbH is headquartered in Munich, Germany. Checkmk focuses on infrastructure monitoring (servers, networks, containers) rather than APM-layer application tracing, but for teams whose New Relic usage is primarily infrastructure visibility rather than application-level APM, Checkmk provides a fully EU-native managed option with no CLOUD Act exposure.

Migration Path from New Relic

Migrating from New Relic to an EU-native alternative involves four areas:

Agent replacement. New Relic uses proprietary agents (Java, .NET, Node.js, Python, etc.). All major EU-native alternatives support OpenTelemetry, which means migrating to an OTel-instrumented codebase positions you for any EU-native destination. Install the OpenTelemetry SDK, replace New Relic agent calls with OTel spans, and point your exporter at your chosen backend.

Dashboard migration. New Relic Query Language (NRQL) dashboards must be rewritten in PromQL, LogQL, or the native query language of your new backend. This is the highest-effort migration step. For complex dashboards, expect one to two days of engineering time per dashboard set.

Alerting migration. New Relic alert conditions export to JSON but do not import directly to Prometheus Alertmanager or Grafana Alerting. The alert logic is preserved; the format requires conversion.

Retention and data export. Before cancelling New Relic, export any historical trace or log data you need to retain for compliance purposes. New Relic provides data export APIs. For GDPR purposes, decide whether historical data needs to be retained or can be deleted — the deletion may itself be a GDPR Article 17 compliance event.

For most teams, a parallel-run period of two to four weeks (New Relic alongside the new stack) allows validation of coverage before decommissioning.

Hosting Observability Infrastructure on sota.io

If you are moving to a self-hosted Grafana LGTM stack or SigNoz and want to avoid the operational overhead of managing the underlying VM infrastructure, sota.io provides EU-native managed hosting with git-push deployment, no US parent, and full CLOUD Act-free data residency.

Deploy your LGTM stack on sota.io the same way you deploy any application: push a docker-compose configuration, configure persistent volumes for Loki, Tempo, and Mimir storage, and your observability infrastructure runs on EU servers with an EU company as your hosting provider. All data remains within EU jurisdiction under your control.

For teams evaluating the build-vs-buy decision on EU-native observability infrastructure, this combination — open source LGTM or SigNoz stack, deployed on EU-native PaaS — provides full-feature observability with no CLOUD Act exposure and no proprietary vendor lock-in.

Summary

New Relic's EU data center, GDPR DPA, and SCC framework address EU-to-US transfer compliance. They do not address CLOUD Act compelled disclosure, which applies because New Relic is a US company under US private equity ownership.

APM and observability data is GDPR-relevant for most production SaaS applications: traces capture user request paths, error messages capture user-identifying values, logs capture activity that relates to identifiable persons.

EU-native alternatives that structurally remove CLOUD Act exposure: self-hosted Grafana LGTM stack (zero US data controller), SigNoz (open source, self-hosted), Elastic Cloud EU with Netherlands contracting entity, VictoriaMetrics (German GmbH), and Checkmk (Munich GmbH).

The migration path from New Relic is OpenTelemetry instrumentation plus backend replacement — a one-time investment that positions you for any future EU-compliant observability destination.