Sentry EU Alternative 2026: GDPR, CLOUD Act & PII in Stack Traces — What Every European SaaS Developer Must Know

If your European SaaS product uses Sentry for error tracking, personal data is flowing to a US-controlled data processor every time an unhandled exception occurs in your application. The data that travels with each error event includes not just a stack trace — it includes the full HTTP request context, user session identifiers, breadcrumbs recording user actions, and often the values of local variables at every frame in the call stack.

Sentry is a US corporation headquartered in San Francisco. Under the CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018), US law enforcement agencies can compel Sentry to produce stored data regardless of whether that data is physically stored in Sentry's EU data centre in Frankfurt. EU infrastructure does not create EU legal jurisdiction over a US company's data.

This guide covers what Sentry actually captures in a typical error event, which GDPR obligations it triggers, why the PII exposure in error tracking is higher than most teams have assessed, and how to migrate to an EU-sovereign error tracking solution in 2026.

What Sentry Captures in a Typical Error Event

Most developers think of error tracking as capturing stack traces — a list of function calls and line numbers. In practice, the Sentry SDK captures far more context with every error event, and much of that context contains personal data under GDPR's broad definition in Article 4(1).

User Context

The Sentry SDK allows — and documentation actively encourages — setting user context on the Sentry scope before errors are reported. The standard pattern:

Sentry.setUser({
  id: user.id,
  email: user.email,
  username: user.username,
  ip_address: request.ip,
});

Once set, this user context is attached to every subsequent error event from that session. An email address, user ID, and IP address are all personal data. Any error that occurs while a user is authenticated will carry this context to Sentry's servers unless you explicitly exclude it.

Even without explicit user context setting, Sentry automatically captures the client IP address from HTTP request headers and attaches it to error events by default.

Request Context

For server-side SDKs (Python, Node.js, Ruby, PHP, Java, .NET), Sentry automatically captures the full HTTP request context with each error:

URL and query string: may contain user-identifying parameters, search terms, filter values
HTTP method and headers: Authorization headers (tokens), Cookie headers (session IDs), User-Agent
Request body: POST data, JSON payloads, form submissions — all captured by default for many framework integrations

The request body is particularly high-risk. A POST /api/users/{id}/profile endpoint that fails while processing a profile update will send the entire profile update payload — containing name, address, phone number, or whatever was being updated — to Sentry. This is not a theoretical scenario. It is the default behaviour of Sentry's framework integrations.

Local Variable Values in Stack Frames

This is the aspect of Sentry's data collection that is least commonly understood and highest risk for GDPR compliance.

Sentry's server-side SDKs can capture the values of local variables at each frame in the call stack at the moment an exception is raised. This feature is not universally enabled — it requires include_local_variables=True in Python, for example — but it is available and documented as a debugging aid.

When enabled, if your exception occurs inside a function that has a user object in scope, Sentry will capture the fields of that object. If you have a database cursor object in scope that was executing a query with PII in the WHERE clause, Sentry may capture the query. If you have a request object in scope, Sentry may capture fields from the request including authentication credentials.

Even when local variable capture is disabled at the SDK level, the exception message itself may contain PII. An IntegrityError: UNIQUE constraint failed: users.email — duplicate key value: user@example.com exception will carry the user's email address in the exception message to Sentry. This is a common pattern in Django and Rails applications.

Breadcrumbs

Breadcrumbs are a trail of events Sentry captures leading up to an error — HTTP requests made by the application, database queries executed, console log messages. The Sentry SDK captures breadcrumbs automatically from common frameworks.

Database query breadcrumbs may include parameterised query text that reveals which user record was being accessed. HTTP request breadcrumbs from outgoing API calls may include URLs with user-identifying path parameters. Console log breadcrumbs capture your application's log output, which may include user identifiers you have logged for debugging purposes.

Session Replay

Sentry's Session Replay feature — available in the JavaScript browser SDK — captures user interactions in the browser and streams them to Sentry servers. By default, Session Replay uses masking to obscure input field values, but:

Network request and response bodies are captured and must be explicitly scrubbed
Console log output is captured and may contain PII
DOM mutations capturing text content may include dynamically rendered PII

Session Replay creates a particularly high risk of capturing sensitive user data because it operates at the browser level, intercepting everything the JavaScript runtime touches.

Article 44 — Transfers to Third Countries

Sentry is a US company. Sending personal data from your EU users' sessions to Sentry constitutes a transfer to a third country under GDPR Article 44. Sentry participates in the EU-US Data Privacy Framework (DPF), which provides a transfer mechanism following Schrems II.

However, DPF certification does not override the CLOUD Act. Sentry, as a US entity, remains subject to US government data demands regardless of where data is physically stored or which transfer mechanism you use. The DPF itself is under legal challenge (Schrems III litigation is ongoing). If the CJEU invalidates the DPF, companies relying on it for Sentry data transfers would face immediate compliance failures with no grandfathering.

The core problem is architectural: error tracking by its nature captures failure states, and failure states are where PII most often leaks into logs and exception messages. Sentry's data flows are structurally more PII-rich than most observability tools because exceptions capture application state at a moment of failure — precisely when request context, user session data, and database query results are most likely to be in scope.

Article 28 — Data Processing Agreement

Sending personal data to Sentry requires a GDPR-compliant Data Processing Agreement (DPA) in place before any personal data is processed. Sentry provides a DPA, but engineering teams commonly instrument applications with Sentry before legal review of the DPA has occurred.

Your DPA with Sentry must document:

The subject matter and duration of processing
The nature and purpose of processing (error tracking, performance monitoring)
The type of personal data processed (user identifiers, IP addresses, request data)
The categories of data subjects (your end users)

You must also include Sentry in your sub-processor disclosures to data subjects and in your Records of Processing Activities (Article 30 RoPA). If Sentry is acting as a sub-processor — processing data on your behalf — and you did not disclose this in your privacy policy, you have a transparency violation under Article 13/14.

Article 25 — Data Protection by Design and Default

GDPR Article 25 requires data protection by design and by default. For error tracking, this principle has concrete implications:

Before-capture scrubbing: the Sentry SDK provides before_send hooks and beforeSend callbacks that allow you to scrub PII from events before they are transmitted. If you use Sentry and have not implemented event scrubbing for your user context, request bodies, and exception messages, you are not compliant with Article 25.

Data minimisation: Article 5(1)(c) requires that personal data be adequate, relevant, and limited to what is necessary. Capturing the full HTTP request body with every error is not limited to what is necessary for debugging. A stack trace, error message, and request URL (with PII query parameters removed) are usually sufficient.

Automatic IP collection: Sentry captures IP addresses by default. If IP addresses are not necessary for your debugging use case, disabling this default is an Article 25 requirement, not an optional optimisation.

Article 32 — Security of Processing

Routing error events containing PII to a third-party cloud vendor creates an additional breach surface. If your Sentry organisation is compromised — through a stolen API key, a phishing attack on a team member's Sentry account, or a breach of Sentry's infrastructure — all historical error events containing PII are exposed.

Sentry stores events for 90 days by default on the paid plans. For a European SaaS with thousands of daily active users, 90 days of error events containing user context represents a significant corpus of personal data held by a third party outside your direct control.

Sentry's EU Region: What It Does and Does Not Solve

Sentry offers an EU data storage region (sentry.io with EU region selection, or de.sentry.io for Germany-specific routing). Data stored in Sentry's EU region is physically located in Frankfurt.

What the EU region does:

Keeps data at rest in EEA territory
May reduce latency for EU-based applications
Demonstrates a degree of GDPR awareness from Sentry

What the EU region does not do:

Remove Sentry's status as a US company subject to CLOUD Act obligations
Override US government authority to demand data from a US company
Make Sentry employees in the US unable to access EU-region data for support purposes
Substitute for a proper GDPR Article 28 DPA and RoPA documentation
Eliminate the need for beforeSend scrubbing of PII from error events

Selecting the EU region reduces (but does not eliminate) GDPR transfer risk. It does not convert Sentry into a GDPR-compliant solution. European companies handling sensitive personal data, operating under NIS2 obligations, or building for regulated industries (healthcare, finance, legal) need a more robust solution.

NIS2 and the Supply Chain Risk Angle

The NIS2 Directive (EU 2022/2555) entered force in October 2024 across EU member states. Article 21(2)(d) explicitly requires organisations to address "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers."

Error tracking vendors sit at a privileged point in your application's supply chain. They receive telemetry from your production systems and — by design — capture failure states. A compromise of your error tracking vendor affects:

The confidentiality of your users' personal data embedded in error events
The integrity of your debugging workflow (poisoned error events could mask production attacks)
The availability of your incident response capability (if error tracking goes down, so does your ability to identify and respond to production incidents)

Under NIS2, you must document and assess this supply chain risk. For organisations in sectors covered by NIS2 (cloud providers, digital infrastructure, managed services, online marketplaces, DNS providers), this assessment is mandatory. Using a US-headquartered error tracking vendor with access to production exception data is a supply chain risk that must be documented and mitigated.

EU-Sovereign Error Tracking Alternatives

Self-Hosted Sentry

Sentry is open source (BSL licence for some components, MIT for others). Running Sentry on your own EU infrastructure using their official Docker Compose setup gives you full data sovereignty:

git clone https://github.com/getsentry/self-hosted.git
cd self-hosted
./install.sh
docker compose up -d

Self-hosted Sentry runs on a single server with at least 4 CPU cores, 8 GB RAM, and 20 GB disk space. On EU-sovereign infrastructure (such as sota.io's European PaaS), this means error events never leave EU jurisdiction.

The operational overhead is meaningful — you manage Redis, PostgreSQL, ClickHouse, and the Sentry application stack. For teams without the capacity to operate this, consider managed open-source alternatives.

GlitchTip

GlitchTip is an open-source, Sentry-compatible error tracking platform written in Python (Django). It accepts Sentry SDK events via the Sentry protocol, meaning you can switch by changing your DSN — no SDK changes required.

Key properties:

Sentry SDK compatible (drop-in DSN replacement)
Significantly lower resource requirements than self-hosted Sentry
EU-deployable on any EU cloud provider
PostgreSQL backend (simpler to operate than Sentry's ClickHouse dependency)
Supports Sentry's beforeSend scrubbing hooks

// Change only your DSN — all SDK behaviour remains identical
Sentry.init({
  dsn: "https://your-key@your-glitchtip-instance.example.com/1",
  // All other configuration unchanged
});

GlitchTip lacks some of Sentry's advanced features (Session Replay, full Performance APM), but for error tracking and basic performance monitoring, it is a complete Sentry-compatible replacement.

Bugsink

Bugsink is a newer, intentionally minimal Sentry-compatible error tracking server. It is designed for self-hosting with a single Docker container and SQLite, making it the lowest-overhead EU-deployable option:

docker run -d \
  -p 8000:8000 \
  -e SECRET_KEY=your-secret-key \
  -v bugsink-data:/app/data \
  bugsink/bugsink:latest

Bugsink is appropriate for smaller teams that need Sentry SDK compatibility without the operational complexity of full Sentry or GlitchTip.

Highlight.io EU Deployment

Highlight.io is an open-source observability platform (errors + session replay + logs) that can be self-hosted. It covers the Session Replay use case that GlitchTip and Bugsink do not address.

Migration Checklist: From Sentry Cloud to EU-Sovereign Error Tracking

Phase 1: Audit Current PII Exposure (Week 1)

Review your Sentry organisation settings: is user context being captured? Is request body capture enabled?
Check your Sentry.setUser() calls — what PII fields are you sending?
Review framework integrations: Django, Flask, Express, Rails, Laravel all have auto-capture behaviours that may not be documented in your codebase
Audit exception messages: do any contain email addresses, names, or IDs from database constraints?
Check if Session Replay is enabled and assess what data it captures
Review your Sentry DPA — is it signed? Is Sentry in your RoPA and privacy policy?

Phase 2: Implement beforeSend Scrubbing (Week 1-2)

Even if you migrate to EU-sovereign infrastructure, implement beforeSend scrubbing as defence in depth:

# Python/Django example
def before_send(event, hint):
    # Remove request body from all events
    if "request" in event:
        event["request"].pop("data", None)
        event["request"].pop("cookies", None)
        # Preserve URL but scrub query string PII
        
    # Remove user email, keep only ID
    if "user" in event:
        event["user"] = {"id": event["user"].get("id")}
    
    return event

sentry_sdk.init(
    dsn="...",
    before_send=before_send,
)

// JavaScript/Next.js example
Sentry.init({
  dsn: "...",
  beforeSend(event) {
    // Remove user PII from event
    if (event.user) {
      event.user = { id: event.user.id };
    }
    // Remove request body
    if (event.request?.data) {
      delete event.request.data;
    }
    return event;
  },
});

Phase 3: Deploy EU-Sovereign Error Tracking Instance (Week 2-3)

Deploy GlitchTip or self-hosted Sentry on EU-sovereign infrastructure. If you use a PaaS platform operating within the EU under GDPR-compliant terms, you get managed infrastructure without the CLOUD Act exposure.

# docker-compose.yml for GlitchTip on EU PaaS
version: "3"
services:
  web:
    image: glitchtip/glitchtip:latest
    environment:
      DATABASE_URL: postgres://glitchtip:password@db/glitchtip
      SECRET_KEY: your-secret-key-here
      EMAIL_URL: smtp://your-smtp-server
      GLITCHTIP_DOMAIN: https://errors.yourdomain.eu
    depends_on:
      - db
  db:
    image: postgres:15-alpine
    volumes:
      - postgres_data:/var/lib/postgresql/data
    environment:
      POSTGRES_DB: glitchtip
      POSTGRES_USER: glitchtip
      POSTGRES_PASSWORD: password
volumes:
  postgres_data:

Phase 4: Switch DSN and Verify (Week 3-4)

# Before
sentry_sdk.init(dsn="https://key@sentry.io/project-id")

# After (GlitchTip on your EU instance — no other changes needed)
sentry_sdk.init(dsn="https://key@errors.yourdomain.eu/1")

Verify:

Test errors appear in your EU-sovereign instance
HTTP-check your Sentry SDK integration to confirm events are no longer flowing to sentry.io
Update your DPA documentation to reference the EU-sovereign processor
Update your privacy policy sub-processor list
Remove Sentry from your RoPA GDPR transfer documentation

Phase 5: Documentation and Compliance (Week 4)

Update RoPA Article 30 to remove Sentry and add your EU-sovereign error tracking
Update privacy policy to remove Sentry from sub-processor list
Document the beforeSend scrubbing configuration in your security documentation
Add error tracking to your NIS2 supply chain risk documentation as EU-sovereign

What to Do If You Cannot Migrate Immediately

If immediate migration is not possible, implement these mitigations to reduce GDPR exposure while Sentry Cloud is still in use:

Enable Sentry's EU region in your organisation settings (sentry.io → Settings → Organisation → Data Storage Region → EU)
Implement beforeSend scrubbing for request bodies, user email addresses, and sensitive exception message patterns
Disable Session Replay unless you have explicit user consent per GDPR Article 6(1)(a)
Sign the Sentry DPA and include Sentry in your RoPA and privacy policy sub-processor list
Set data retention to the minimum needed (7 or 30 days rather than 90)
Disable IP collection: set send_default_pii=False in your SDK initialisation

These mitigations reduce but do not eliminate the fundamental CLOUD Act exposure. They are a temporary measure while migration is planned.

The Sota.io Angle: EU-Sovereign PaaS for Self-Hosted Error Tracking

Running GlitchTip or self-hosted Sentry requires a hosting provider. The provider's legal status matters: if you deploy GlitchTip on AWS Frankfurt, your data is sovereign in terms of location but still subject to AWS's legal obligations as a US company.

EU-sovereign PaaS platforms — infrastructure operated by EU-headquartered companies under EU law — eliminate the CLOUD Act exposure at the infrastructure level. This is the structural difference between hosting on US-owned infrastructure in Europe and hosting on EU-owned infrastructure in Europe.

When you run your error tracking on EU-sovereign PaaS:

Error events containing user PII stay in EU legal jurisdiction end-to-end
No US government compulsion order can reach your error tracking data
NIS2 supply chain risk is limited to EU-regulated entities
GDPR Article 44 third-country transfer risk is eliminated
Your DPA chain involves only EU-headquartered data processors

For European SaaS teams handling GDPR-regulated personal data, this is not a minor compliance detail. Error tracking captures your production failures — the moments when your system state is least controlled and most likely to expose sensitive data. The error tracking infrastructure is one of the highest-priority data flows to bring under EU-sovereign control.

Conclusion

Sentry is an excellent error tracking tool, and the PII exposure through stack traces and error events is not a reason to abandon error tracking. It is a reason to self-host your error tracking on EU-sovereign infrastructure.

The migration path is straightforward: GlitchTip accepts Sentry SDK events via a protocol-compatible DSN change. Self-hosted Sentry runs on a single server. beforeSend scrubbing can reduce PII exposure on any error tracking backend.

The GDPR obligations are clear. Error events from your production application contain personal data. Sending that data to a US company under US legal jurisdiction constitutes an Article 44 third-country transfer that requires a compliant legal basis, a signed DPA, RoPA documentation, and privacy policy disclosure.

For European SaaS teams building under GDPR, NIS2, or DORA, EU-sovereign error tracking is not a compliance nicety. It is the correct default architecture.

Running GlitchTip or self-hosted Sentry on EU-sovereign infrastructure? sota.io provides European PaaS without CLOUD Act exposure — deploy your error tracking stack with a single git push to infrastructure that stays in EU legal jurisdiction.