PagerDuty EU Alternative 2026: Why NYSE-Listed PagerDuty Is a CLOUD Act Risk in Your Incident Pipeline — and What EU Teams Use Instead

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

PagerDuty occupies the same uncomfortable position in EU compliance conversations that Datadog, Grafana Cloud, and Splunk do: it is a best-in-class SaaS tool that millions of teams depend on for production reliability, and it is a US company subject to US law in ways that Standard Contractual Clauses cannot fix.

The incident management category has a specific GDPR wrinkle that distinguishes it from pure observability tooling. PagerDuty does not just process telemetry data — it processes personal data about your operations team members: who is on call this week, which engineer's phone number to dial at 3 AM, who acknowledged the incident and when. It also receives alert payloads from your monitoring stack, and those payloads frequently contain fragments of customer PII embedded in error messages, stack traces, and log lines.

This guide explains what GDPR-relevant data PagerDuty processes, what the US CLOUD Act means for EU organisations using PagerDuty, and which EU-sovereign incident management platforms give teams genuine data protection without sacrificing on-call reliability.

What PagerDuty Processes and Why It Is GDPR-Relevant

PagerDuty's core function is routing alerts to on-call engineers and managing the lifecycle of operational incidents. To perform this function, it necessarily processes several categories of personal data.

On-call schedules and contact information. PagerDuty stores the rotational schedules that determine which engineer is responsible for which service at what time. These schedules contain the names, email addresses, and mobile phone numbers of every engineer in your on-call pool. Mobile phone numbers are personal data under GDPR Article 4(1). PagerDuty uses these numbers to deliver SMS alerts and voice calls during escalation. Every time PagerDuty pages an engineer, it processes personal contact data as part of its core function.

For NIS2-regulated organisations — those operating critical infrastructure or essential services — the on-call schedules in PagerDuty describe the operational structure of your incident response capability. Storing this information with a US SaaS provider creates a concentration of sensitive operational intelligence in a system subject to US legal demands.

Alert payloads from monitoring integrations. PagerDuty integrates with monitoring tools including Datadog, Grafana, Prometheus Alertmanager, CloudWatch, New Relic, and dozens of others via its Events API. When an alert fires, the monitoring tool sends a payload to PagerDuty describing the alert. That payload is largely defined by the monitoring tool's alerting rules — and those rules are routinely written by engineers who include useful diagnostic context such as the user account that triggered an error, the customer ID associated with a failing request, the email address in a failed login event, or the order number in a payment processing failure.

Engineers write alerting rules to help diagnose incidents. They do not typically think of those rules as configuring personal data flows to a US SaaS provider. But the alert payload that PagerDuty receives and stores for the duration of the incident — and often permanently in incident history — may routinely contain fragments of customer personal data that the organisation is responsible for under GDPR Article 5(1)(b) (purpose limitation) and Article 5(1)(c) (data minimisation).

Incident records and timelines. PagerDuty maintains a complete record of each incident: when it was created, what triggered it, which engineer acknowledged it, what notes were added during the incident, when it was resolved, and who was involved. Incident notes are free-text and routinely contain diagnostically useful personal data that engineers type during incident response ("customer john.doe@example.com can't log in", "affecting tenant ID 7842", "rolled back to commit 4af9c3b affecting EU East region users").

Status page subscribers. PagerDuty's status page product (PagerDuty Status Pages) collects email addresses of subscribers who opt in to incident notifications. These are unambiguously personal data. Status page subscribers are often customers of the organisation running the status page.

Integration credentials and webhook endpoints. PagerDuty stores the API keys, webhook URLs, and service account credentials that connect it to your monitoring and ticketing stack. While these are not personal data under GDPR, they represent significant security-sensitive operational information whose exposure in a legal proceeding or breach would have consequences beyond data protection law.

The cumulative picture is that a typical enterprise PagerDuty account contains personal data about the organisation's own engineering team, personal data fragments from customer-facing systems embedded in alert payloads and incident notes, and email addresses of status page subscribers. All of this data sits in PagerDuty's SaaS infrastructure under US corporate control.

PagerDuty's Corporate Structure: Delaware Incorporation and NYSE Listing

PagerDuty, Inc. was incorporated in Delaware, USA and has been headquartered in San Francisco, California since its founding in 2009. The company went public on the New York Stock Exchange (NYSE: PD) in April 2019.

PagerDuty operates European offices and employs engineers and sales staff across multiple EU member states. These local presences are European subsidiaries of the US parent corporation — they do not control the SaaS platform, do not hold the data processing relationship with European customers, and do not change the corporate nationality of the entity that processes customer data.

As a US-incorporated, NYSE-listed company, PagerDuty is unambiguously subject to US law including the CLOUD Act and US domestic subpoenas. Its DPA (Data Processing Addendum) and EU GDPR compliance documentation describe Standard Contractual Clauses and other transfer mechanisms. None of these instruments modify what US law requires of PagerDuty as a US company.

PagerDuty has APEC CBPR certification, SOC 2 Type II certification, and ISO 27001 certification. These certifications address security controls and practices. They do not address CLOUD Act exposure.

US CLOUD Act: Why "EU Data Processing" Does Not Solve the Problem

The CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 18 U.S.C. § 2713) requires US companies to preserve and disclose data in response to valid US legal demands regardless of whether that data is stored inside or outside the United States.

PagerDuty offers European data residency through agreements with enterprise customers, routing certain data processing to European AWS regions. The physical location of PagerDuty's data centres does not affect its CLOUD Act obligations. If the US Department of Justice or another authorised US agency serves PagerDuty with a valid CLOUD Act demand, PagerDuty is required by US law to produce the requested data whether it is stored in us-east-1 or eu-central-1.

Standard Contractual Clauses do not address CLOUD Act exposure. SCCs are contractual instruments governing your organisation's transfer of personal data to PagerDuty as your data processor. They create obligations that PagerDuty accepts toward your organisation about how it handles your data. SCCs cannot modify what US domestic law requires PagerDuty to do when it receives a CLOUD Act order. CLOUD Act compliance obligations run between PagerDuty and the US government — your contractual relationship with PagerDuty is not part of that relationship.

The practical consequence for EU data controllers using PagerDuty: you cannot guarantee that the personal data you send to PagerDuty — on-call contact information, alert payload fragments, incident notes — will not be disclosed to US authorities under CLOUD Act process. You cannot contractually prevent it. You cannot be notified when it happens (gag orders are standard in CLOUD Act proceedings). You cannot retroactively comply with your GDPR obligations to protect EU data subjects if their personal data has been disclosed under CLOUD Act process.

For most organisations, the residual risk is low in practice. Few organisations are targets of US legal proceedings that would generate CLOUD Act demands for their PagerDuty incident data. But GDPR compliance requires assessment of legal risk, not just practical likelihood. If your data protection impact assessment or your DPA agreement states that PagerDuty is a GDPR-compliant processor for personal data, that statement requires that the CLOUD Act exposure be either assessed as acceptable or mitigated.

For organisations subject to NIS2, DORA, or operating in sectors where supply chain data exposure is regulated, the CLOUD Act risk in incident management tooling is increasingly a procurement concern.

DORA Implications for Financial Sector Organisations

The Digital Operational Resilience Act (DORA, Regulation (EU) 2022/2554) applies to financial sector entities including banks, insurers, investment firms, and their ICT service providers. DORA Article 28 establishes requirements for ICT third-party service provider relationships including concentration risk assessment, exit strategies, and contractual rights of audit.

PagerDuty, used as an incident management platform by financial sector organisations, is an ICT third-party service provider under DORA. DORA Article 30 specifies minimum contract provisions required in agreements with ICT service providers, including provisions on data location, audit rights, and subprocessor control.

For DORA-regulated entities using PagerDuty, the CLOUD Act exposure creates a specific tension: DORA requires clear understanding of where ICT data is processed and under what legal framework, while CLOUD Act creates a framework where the legal jurisdiction over PagerDuty's data obligations includes US domestic law that overrides contractual data location commitments.

DORA's concentration risk provisions also become relevant for large PagerDuty deployments: if a significant portion of EU financial sector incident management depends on a single US SaaS platform, sector-wide CLOUD Act exposure creates systemic risk concentration.

EU-Sovereign Incident Management Alternatives

The EU incident management market has matured significantly. Teams migrating from PagerDuty for data sovereignty reasons now have functional alternatives that do not carry US CLOUD Act exposure.

ilert (German, EU-Sovereign)

ilert GmbH is incorporated in Germany and headquartered in Cologne. It provides an incident management and on-call scheduling platform directly competitive with PagerDuty in feature scope: alert routing, escalation policies, on-call rotations, incident timelines, and integrations with Prometheus, Grafana, Datadog, and other monitoring tools.

ilert's data processing infrastructure is hosted in EU data centres without US corporate parent involvement. As a German GmbH, it is subject to German and EU law — not US CLOUD Act obligations. For organisations that need written confirmation of no US CLOUD Act exposure, ilert can provide this as part of its commercial DPA.

ilert's pricing is comparable to PagerDuty for equivalent team sizes. The feature parity for standard on-call use cases — alert routing, escalation policies, schedules, acknowledgment workflows — covers the needs of most teams without requiring PagerDuty's full feature catalogue.

Practical migration path from PagerDuty to ilert:

1. Export on-call schedules from PagerDuty (CSV export available in account settings)
2. Import escalation policies into ilert via its API or UI
3. Update monitoring integrations to ilert's event API endpoints (Prometheus, Grafana, and Datadog have native ilert integrations)
4. Migrate engineer contact information and notification preferences
5. Run parallel alerting for one rotation cycle to validate routing

The migration takes approximately one to two working days for a team of 20 engineers and a moderate number of services.

SIGNL4 by Derdack (German, EU-Sovereign)

Derdack GmbH is a German company headquartered in Potsdam, Brandenburg. Its SIGNL4 product provides mobile alerting and on-call management focused on operational teams including IT, industrial IoT, and field service operations.

SIGNL4 covers the core PagerDuty use case — delivering alerts to on-call engineers via push notification, SMS, and voice call, with acknowledgment and escalation workflows. It integrates with monitoring tools via webhook, email, and API. As a German GmbH, Derdack processes data under EU jurisdiction with no CLOUD Act exposure.

SIGNL4 is particularly well-suited for operational technology (OT) environments where GDPR and NIS2 concerns overlap with industrial control system monitoring.

Self-Hosted Grafana OnCall

Grafana OnCall is the open-source on-call management component extracted from Grafana Cloud. It is available under the Apache 2.0 licence and can be deployed on EU-controlled infrastructure independently of Grafana Cloud.

Self-hosted Grafana OnCall provides on-call schedules, escalation policies, alert routing, and incident management workflows functionally equivalent to PagerDuty's core features. It integrates natively with Grafana alerting (including Prometheus Alertmanager via Grafana's unified alerting) and supports webhooks for other monitoring tools.

Deploying Grafana OnCall on EU-controlled infrastructure — whether a self-managed VM, a managed Kubernetes cluster, or a platform-as-a-service provider incorporated under EU law — eliminates CLOUD Act exposure entirely. The data never leaves your infrastructure boundary.

The operational overhead of self-hosting Grafana OnCall is meaningful but manageable. The primary requirements are a PostgreSQL database for incident storage, a Redis cache, and a Grafana instance for the UI. The Grafana OnCall Helm chart handles Kubernetes deployment. For teams already running self-hosted Grafana (itself a common pattern for EU compliance), adding OnCall to the deployment is straightforward.

Alertmanager with EU-Hosted Routing

For teams with simpler on-call requirements — routing Prometheus alerts to engineers with basic escalation logic — Prometheus Alertmanager combined with an EU-hosted notification layer provides a genuinely minimal CLOUD Act-free solution.

Alertmanager handles alert routing, grouping, and silencing. For notification delivery, EU-hosted options include:

• ntfy.sh (self-hostable, open-source push notification service)
• Grafana OnCall (as the on-call routing layer)
• Email via an EU-hosted mail provider
• SMS via EU-incorporated gateway providers (e.g., Vonage EU entities, Twilio Germany GmbH for EU-located data)

This approach works well for smaller teams with clear incident routing needs and a preference for minimal tooling dependency.

What Stays in EU Jurisdiction: The Technical Comparison

Migration Considerations: Personal Data Deletion from PagerDuty

When migrating from PagerDuty to an EU-sovereign alternative, GDPR Article 17 (right to erasure) creates a specific obligation: personal data of EU data subjects held by PagerDuty — on-call engineer contact information, incident notes referencing individuals, alert payloads containing customer PII — should be deleted from PagerDuty's systems after migration.

PagerDuty's data deletion process for account termination is documented in its privacy policy and DPA. The practical steps:

1. Export incident history before account cancellation. PagerDuty provides CSV and JSON export of incident data. Retain this for your own records if needed for post-incident analysis.
2. Remove engineer contact data (phone numbers, email addresses) from PagerDuty user accounts before or at cancellation.
3. Request account deletion via PagerDuty's account management process (requires account owner credentials).
4. Document the deletion request with date and confirmation. Under GDPR Article 30, your records of processing should reflect the termination of this processing relationship.
5. Verify deletion confirmation from PagerDuty and retain the confirmation for your Article 30 documentation.

PagerDuty's standard retention after account deletion is governed by its DPA. Confirm with PagerDuty in writing what the deletion timeline is before migrating if you need GDPR-precise guarantees.

Practical Decision Framework for EU Teams

The decision between PagerDuty and an EU-sovereign alternative involves trade-offs beyond CLOUD Act compliance:

Assess your actual PagerDuty data footprint first. Review what alert payloads your monitoring integrations are sending to PagerDuty. If your alert payloads contain customer PII routinely — user IDs, email addresses, account numbers — your CLOUD Act exposure is higher than for teams with purely infrastructure-level alerts. Instrument your monitoring rules to minimise personal data in alert payloads regardless of which platform you use.

Evaluate the feature requirements for your team size. PagerDuty has a deep feature catalogue including analytics, incident management AI (PagerDuty Advance), extensive third-party integrations, and enterprise controls. ilert and Grafana OnCall cover the core on-call use case well for most teams. If your primary use is routing alerts and managing escalation policies, the functional gap is small. If you depend heavily on PagerDuty Analytics or specific enterprise integrations, evaluate the alternatives carefully.

Account for the operational burden of self-hosting. Grafana OnCall on self-hosted infrastructure eliminates CLOUD Act exposure and vendor dependency simultaneously. It also adds infrastructure operations responsibility. For teams with existing Kubernetes infrastructure and Grafana deployments, this is manageable. For teams without infrastructure operations capacity, ilert's managed EU SaaS offering is the lower-overhead path to EU sovereignty.

Check NIS2 and DORA applicability to your organisation. If your organisation is in scope for NIS2 or DORA, the compliance pressure to document and mitigate ICT third-party supply chain risks — including CLOUD Act exposure in incident management tooling — is increasing. Use this as the business case for the migration conversation.

Incident Management Data Is Personal Data: The GDPR Baseline

The European Data Protection Board's guidance on data processor relationships (Guidelines 07/2020) confirms that the data controller remains responsible for personal data processed by its processors — including data that enters the processor relationship incidentally through operational practices rather than by explicit design.

Teams that use PagerDuty have likely not conducted a specific GDPR analysis of whether their alert payloads contain personal data. The answer in most production environments is: yes, routinely. The appropriate response under GDPR Article 5(1)(b) (purpose limitation) and Article 25 (data protection by design and default) is to minimise personal data in alert payloads where possible, and to ensure that the processor handling that data provides adequate protection under Article 28.

Adequate protection includes a structural guarantee that the processor's corporate jurisdiction does not create legal access pathways inconsistent with EU data protection expectations. PagerDuty, as a US-incorporated company subject to the CLOUD Act, does not provide that structural guarantee for the on-call contact data and alert payload fragments it processes on your behalf.

EU-incorporated alternatives including ilert and self-hosted Grafana OnCall on EU infrastructure provide that structural guarantee. The migration effort is bounded and the feature gap for standard use cases is small.

For EU organisations reassessing their incident management stack under NIS2, DORA, or general GDPR compliance review, this is a well-defined migration with a clear outcome: incident data, on-call contact information, and alert payloads stay within EU jurisdiction and out of reach of US CLOUD Act demands.