Dynatrace EU Alternative: Austrian Headquarters Doesn't Prevent US CLOUD Act Exposure — What EU Developers Use Instead

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

Dynatrace occupies an unusual position among observability vendors. It was founded in Linz, Austria in 2005. Its engineering headquarters remain partly in Europe. The company's origin story is distinctly non-American. For EU developers evaluating APM and full-stack observability platforms under GDPR, this European heritage appears to signal meaningful data protection advantages over purely US-origin competitors like Datadog or New Relic.

It does not. The determining legal factor for CLOUD Act exposure is not where a company was founded. It is where the controlling corporate entity is incorporated. Dynatrace, Inc. — the parent company that operates Dynatrace's SaaS platform, holds its customer data, and controls its infrastructure — is incorporated in Delaware, USA. As a US-incorporated company, Dynatrace, Inc. is subject to the US CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 18 U.S.C. § 2713), which requires US companies to produce data stored anywhere in the world when presented with a valid US law enforcement order.

Austrian headquarters, EU data residency options, and GDPR-compliant data processing addenda do not change this structural reality. The confusion is understandable but consequential for EU compliance.

What Dynatrace Observability Data Is GDPR-Relevant

Before examining the CLOUD Act implications, it is worth understanding what data Dynatrace actually collects — because developers frequently underestimate the GDPR relevance of observability telemetry.

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

OneAgent traces and distributed traces. Dynatrace OneAgent instruments your application automatically using byte code instrumentation. It captures HTTP requests, database calls, external service calls, and the transaction paths connecting them. When a traced request includes a user action — a login, a profile update, a checkout — the trace payload captures request URLs, HTTP headers, and in many configurations, request body fragments. If those URLs contain /api/users/user@example.com or request headers include Authorization: Bearer <token>, the trace data is personal data under GDPR.

Log management. Dynatrace Log Management and Analytics ingests application logs, infrastructure logs, and Kubernetes logs. Application logs routinely contain user-identifiable information: login events, transaction records, validation errors that include the input that triggered them. Even logs that do not explicitly contain PII often contain session tokens or IP addresses that qualify as personal data under GDPR Recital 30.

Real User Monitoring (RUM). Dynatrace RUM captures end-user browser interactions, including IP addresses, browser type, geographic location derived from IP, session duration, and click paths. IP addresses are personal data in the EU context under GDPR Article 4(1) and Recital 30, confirmed by EDPB guidelines and multiple DPA decisions. Dynatrace RUM processes IP addresses by design.

Session Replay. Dynatrace Session Replay captures user interaction recordings — mouse movements, clicks, form interactions, and scroll behaviour. Session Replay data is among the most personal-data-dense telemetry categories in observability. Form interaction data may capture partial keystrokes in fields that users subsequently clear. Even with Dynatrace's masking features enabled, the underlying session data processed during capture is GDPR-relevant before masking is applied.

Infrastructure monitoring. Dynatrace monitors host metrics, container metrics, and Kubernetes cluster state. While infrastructure metrics are less likely to contain personal data, Kubernetes pod labels and annotations frequently include application-layer identifiers — customer IDs, tenant identifiers, environment tags — that can create indirect identification paths under GDPR's broad definition.

Custom dimensions and business events. Dynatrace's business analytics and Davis AI features allow attaching custom dimensions to spans, events, and metrics. Development teams commonly attach user context — subscription tier, user ID, account region — to enable more granular dashboards. All custom dimensions attached to personal-data-bearing transactions become personal data in Dynatrace.

The threshold for GDPR applicability is lower than most teams expect. You do not need to deliberately route PII into Dynatrace for your Dynatrace deployment to process personal data. Automatic instrumentation captures it incidentally from request paths, error messages, and log output.

Dynatrace's Corporate Structure: Delaware, Not Austria

Dynatrace's European identity is genuine in its origins. The company was founded in Linz, Austria by Bernd Greifeneder and his team. It operated as Compuware APM and then as a separate Dynatrace entity for years before a US private equity acquisition and eventual IPO.

The legally relevant corporate history for CLOUD Act purposes is the post-2014 structure:

In 2014, Thoma Bravo — a US private equity firm headquartered in San Francisco and Chicago — acquired the Dynatrace business from Compuware for approximately $900 million. The corporate vehicle created for the acquisition and subsequent operation was Dynatrace Holdings LLC, a Delaware limited liability company.

In 2019, Dynatrace Holdings LLC completed an IPO on the New York Stock Exchange under the ticker DT. Prior to the IPO, the entity converted to Dynatrace, Inc., a Delaware corporation. This is the current parent company for the Dynatrace SaaS platform globally.

Dynatrace has European operating entities — including Dynatrace Austria GmbH (the engineering entity in Linz) and various European subsidiaries used for local contracting and employment. These entities do not control the SaaS platform infrastructure. Dynatrace, Inc. (Delaware) is the entity that operates the SaaS platform, holds data processing agreements with customers, and controls the cloud infrastructure on which customer observability data is processed.

CLOUD Act obligations run to the US parent. The existence of a European engineering headquarters or European subsidiaries does not shield the US parent from CLOUD Act compelled disclosure, and the US parent controls the systems through which CLOUD Act compliance would be executed.

This is structurally identical to the situation with AWS (US parent), Microsoft Azure (US parent), Datadog (US parent), New Relic (US parent), and Splunk (US parent). Geographic origin of the engineering team is not legally relevant. Corporate nationality of the entity controlling the data is.

CLOUD Act Compelled Disclosure: Why SCCs Do Not Help

When EU data protection authorities evaluate Dynatrace's transfer compliance, they examine Standard Contractual Clauses, transfer impact assessments, and whether Dynatrace's DPA commits to appropriate safeguards. Dynatrace provides all of these under its GDPR compliance framework.

The CLOUD Act problem is a different legal question, and SCCs do not address it.

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" when lawfully ordered to do so. This obligation applies regardless of where the data is stored — Frankfurt, Dublin, or Tokyo. A US law enforcement order directed at Dynatrace, Inc. can compel disclosure of data in Dynatrace's EU data centers.

SCCs govern transfers from your organisation to Dynatrace. They establish what Dynatrace must do (or refrain from doing) as your data processor. They do not govern what US law requires Dynatrace to do independently of your contractual relationship with them. The SCC mechanism is a data transfer compliance tool. CLOUD Act is a US domestic law enforcement tool. These instruments operate on different legal planes.

GDPR Article 48 creates an asymmetry: EU-established organisations should not comply with third-country court orders without legal review or an applicable international agreement. This does not prevent US-incorporated entities from complying with US court orders. Dynatrace, Inc. as a US entity is subject to US law, and US law requires compliance with CLOUD Act orders.

The practical risk for EU developers is concrete: if Dynatrace receives a CLOUD Act demand covering data related to your application — because one of your customers is a party to a US legal proceeding, because your US-incorporated parent is under investigation, or because a US regulatory body seeks data about an entity that uses your platform — Dynatrace may be legally required to produce that data. You will not receive advance notice. The disclosed data may include personal data of EU data subjects for which you are the GDPR controller. This creates a GDPR exposure independent of your own compliance posture.

Dynatrace's EU Data Residency Offering: What It Solves and What It Doesn't

Dynatrace offers EU data residency through its Dynatrace SaaS platform deployment options. Customers can select an EU-based Dynatrace Environment hosted in AWS Frankfurt or other EU regions. Dynatrace commits contractually to EU data residency for in-scope customer data.

EU data residency addresses geographic data transfer concerns. It means your observability data does not leave the EU as part of routine processing. Under GDPR's data transfer framework (Chapter V), this is meaningful: it removes the need for GDPR Article 46 transfer mechanisms for the initial ingestion and storage of data.

What EU data residency does not address is CLOUD Act compelled disclosure. The data may be physically stored in Frankfurt. The corporate entity controlling that data — Dynatrace, Inc. — is US-incorporated. A CLOUD Act order directed at Dynatrace, Inc. can reach data stored in Frankfurt through Dynatrace's internal systems. Physical location and legal access are different questions.

The distinction matters for EU risk assessment: EU data residency reduces your data transfer compliance burden. It does not eliminate your CLOUD Act exposure. For controllers handling sensitive personal data (health data, financial data, children's data) under GDPR Article 9 or strict sectoral regulations, the residual CLOUD Act exposure may be material.

EU-Native Observability Alternatives

For EU development teams that need to eliminate structural CLOUD Act exposure from their observability stack, the viable approaches fall into two categories: self-hosted EU infrastructure and EU-incorporated cloud providers.

Self-Hosted OpenTelemetry Stack (Recommended for Data Sovereignty)

The most complete solution to CLOUD Act exposure in observability is self-hosting your observability infrastructure on EU-based hardware under your own control.

OpenTelemetry (CNCF project) provides a vendor-neutral instrumentation framework that replaces Dynatrace OneAgent for trace, metric, and log collection. It supports all major language runtimes and is supported by every EU-sovereign infrastructure provider.

A complete self-hosted stack:

• Traces: Jaeger or Tempo (deployed on your EU infrastructure via Grafana Labs' open source tools)
• Metrics: Prometheus + VictoriaMetrics (VictoriaMetrics is a high-performance time series database developed by a European team, with no US corporate parent)
• Logs: Loki (Grafana Labs, open source) or OpenSearch (AWS-originated but open source, self-hosted)
• Dashboards and alerting: Grafana (open source, self-hostable on EU infrastructure)
• AI/Anomaly detection: Prometheus Alertmanager + MLflow for anomaly models, or open source equivalents

When deployed on EU infrastructure — Hetzner Cloud, IONOS Cloud, OVHcloud, UpCloud, or Exoscale — with no SaaS dependency on US-incorporated vendors, this stack has no CLOUD Act exposure. You control the data. No US entity has a legal obligation to produce it.

The migration path from Dynatrace to an OpenTelemetry-based stack involves:

1. Replacing Dynatrace OneAgent with OpenTelemetry SDK instrumentation in your application code
2. Deploying an OpenTelemetry Collector as your telemetry pipeline
3. Routing traces to Tempo/Jaeger, metrics to Prometheus/VictoriaMetrics, logs to Loki
4. Migrating Dynatrace dashboards to Grafana (Grafana supports Dynatrace dashboard import through community plugins)
5. Recreating alerting rules in Prometheus Alertmanager or Grafana Alerting

The effort is non-trivial for large deployments, but the instrumentation change (OneAgent to OTel SDK) is the primary work. Once instrumentation uses OpenTelemetry, the backend is swappable.

SigNoz: EU-Deployable Open Source APM

SigNoz is an open source APM and observability platform designed as a direct Dynatrace/Datadog alternative. It provides:

• Full distributed tracing with flamegraph views comparable to Dynatrace PurePath
• Infrastructure metrics with host maps
• Log management with correlation to traces
• Exception monitoring with stack trace capture
• Alerting with notification integrations

SigNoz is deployed as a container cluster (Docker Compose or Kubernetes Helm chart). When deployed on EU infrastructure, it creates no US corporate dependency. SigNoz, Inc. is a US company (Y Combinator alumni), but the software is open source (AGPL + Apache 2.0 for instrumentation libraries). Self-hosting eliminates the dependency on SigNoz's cloud.

SigNoz uses ClickHouse for storage, which handles high-cardinality observability data efficiently. It ingests OpenTelemetry protocol (OTLP) natively, making migration from an OTel-instrumented Dynatrace deployment straightforward.

Grafana LGTM Stack on EU Cloud

Grafana Labs offers the LGTM stack (Loki for logs, Grafana for dashboards, Tempo for traces, Mimir for metrics) as either open source self-hosted components or as Grafana Cloud (US entity, CLOUD Act applies to cloud offering). Self-hosted Grafana LGTM on EU infrastructure is EU-sovereign. Grafana Cloud is not — Grafana Labs, Inc. is a Delaware-incorporated company.

The distinction: Grafana's software running on your EU servers has no US corporate exposure. Grafana Cloud's managed service operated by Grafana Labs, Inc. has CLOUD Act exposure identical to Dynatrace.

VictoriaMetrics Cloud (EU Region)

VictoriaMetrics is a high-performance metrics backend developed primarily by European engineers and incorporated outside the US. VictoriaMetrics Cloud offers managed hosting with EU region deployment. For metrics-heavy workloads previously handled by Dynatrace's infrastructure monitoring, VictoriaMetrics provides a Prometheus-compatible backend with Grafana integration and no US corporate exposure in the EU region offering.

Migration Considerations for Dynatrace Customers

EU development teams evaluating a move away from Dynatrace typically face the following migration considerations:

OneAgent vs OpenTelemetry instrumentation. Dynatrace OneAgent's zero-code instrumentation is its primary adoption driver. Migrating to OpenTelemetry requires adding SDK instrumentation to application code, which is a meaningful effort for large codebases. However, OpenTelemetry SDKs now cover all major runtimes with comparable coverage to OneAgent for the majority of use cases. The investment is a one-time instrumentation migration that produces vendor-neutral telemetry permanently.

Davis AI and Automatic Root Cause Analysis. Dynatrace's AI-powered topology mapping and automatic root cause analysis (Davis AI) is a differentiated capability. Open source alternatives provide manual correlation workflows and rule-based alerting without equivalent automatic RCA. For teams that depend heavily on Davis AI, the migration involves accepting more manual investigation workflows or investing in custom anomaly detection pipelines using tools like Prometheus + AlertManager with crafted recording rules.

Session Replay replacement. For teams using Dynatrace Session Replay, EU-sovereign alternatives include self-hosted OpenReplay (open source, self-deployable on EU infrastructure) or PostHog (open source, self-hostable). Both provide session recording with masking controls.

Infrastructure and Kubernetes monitoring. Prometheus + kube-state-metrics + node-exporter provides Kubernetes infrastructure monitoring comparable to Dynatrace's Kubernetes integration, without any US corporate dependency when deployed on EU infrastructure.

Conclusion

Dynatrace's Austrian engineering heritage is historically genuine. The company's commitment to EU data residency and GDPR compliance is reflected in its contractual offerings. These facts matter for data transfer compliance under GDPR Chapter V.

They do not matter for CLOUD Act exposure. Dynatrace, Inc. is incorporated in Delaware. It is a US company subject to US law. A CLOUD Act order directed at Dynatrace, Inc. can reach customer data processed on EU infrastructure. SCCs, DPAs, and EU data residency commitments do not change this.

For EU development teams processing sensitive personal data — health platforms, financial services, legal tech, public sector applications — the residual CLOUD Act exposure from a US-incorporated observability vendor may be material. The EU-sovereign observability stack is buildable: OpenTelemetry instrumentation, self-hosted Grafana LGTM or SigNoz, deployed on EU infrastructure. The path requires instrumentation migration work, but it eliminates the structural dependency on a US corporate entity for your observability data.

If you are building on EU infrastructure and want to deploy your observability stack with GDPR-by-design guarantees, sota.io provides EU-native hosting for containerised workloads including Grafana, Prometheus, Loki, and Tempo — all under EU jurisdiction with no US corporate parent in the data path.