Sentry und Datenschutz
Wer nach „Sentry Datenschutz“ oder „Sentry DSGVO“ sucht, will meistens nicht wissen, wie man Sentry selbst hostet. Die praktischere Frage lautet: Kann ich Sentry als SaaS für eine Anwendung mit europäischen Nutzern verwenden, und was passiert dabei mit meinen Daten?
Die Antwort hat sich seit 2023 deutlich verändert. Sentry bietet inzwischen eine Datenregion in Deutschland an, und für EU-US-Datentransfers gibt es wieder einen Angemessenheitsbeschluss. Damit ist Hosted Sentry heute einfacher aus europäischer Sicht einsetzbar als noch vor einigen Jahren.
Es bleibt aber ein Unterschied zwischen „Daten werden in Deutschland gespeichert“ und „der Anbieter ist europäisch“. Genau dieser Unterschied ist beim Vergleich von Hosted Sentry mit einem europäischen SaaS-Anbieter relevant.
Error Tracking und Datenschutz
Ein Error Tracker bekommt nicht nur den Namen einer Exception. Damit ein Produktionsfehler tatsächlich debugbar wird, enthält ein Event normalerweise Kontext aus der laufenden Anwendung. Je nach SDK und Konfiguration kann das unter anderem sein:
- Stacktrace: Dateinamen, Funktionen und Source Context.
- Request-Daten: URL, HTTP-Methode, Header oder Query-Parameter.
- Nutzerinformationen: User-ID, IP-Adresse oder E-Mail-Adresse.
- Browser- und Gerätedaten: Daten aus Frontend- und Mobile-Anwendungen.
- Tags, Breadcrumbs und lokale Variablen: Kontext aus dem betroffenen Programmablauf.
Sentry nennt in seinem eigenen Data Processing Addendum ausdrücklich unter anderem IP-Adresse, E-Mail-Adresse und andere identifizierbare Daten, die der Kunde über seine Konfiguration an Sentry übermittelt. Das heißt nicht, dass jedes Sentry-Event alle diese Daten enthält. Es heißt aber, dass man Error Tracking nicht sinnvoll als rein technische Verarbeitung ohne Personenbezug behandeln kann. Produktionsdaten haben die unangenehme Eigenschaft, dort aufzutauchen, wo man sie bei der Implementierung nicht erwartet hat.
Ein Fehler kann zum Beispiel mitten in diesem Code entstehen. Der relevante Kontext liegt dann oft in den Variablen und dem Request, nicht im Namen der Exception:
user = find_user(email) subscription = load_subscription(user.id) charge(subscription.payment_method)
Der Error Tracker sieht dann mehr als nur PaymentError. Je nach SDK können
lokale Variablen, Request-Kontext oder eigene Metadaten mitgesendet werden.
Sentrys deutsche Datenregion
Viele ältere deutschsprachige Artikel über Sentry beschreiben noch eine andere Situation. Der eRecht24-Artikel „Datenschutzerklärung für Sentry“ trägt beispielsweise weiterhin den Stand 7. Juni 2023. Dort wird noch davon ausgegangen, dass Sentry Nutzerdaten außerhalb der EU speichert und für den Transfer in die USA Standardvertragsklauseln benötigt werden. Das war zu diesem Zeitpunkt nachvollziehbar; seitdem haben sich zwei wichtige Dinge geändert.
Am 10. Juli 2023 verabschiedete die Europäische Kommission den Angemessenheitsbeschluss für das EU-US Data Privacy Framework. Daten dürfen damit an teilnehmende US-Unternehmen übertragen werden, ohne dass für diesen Transfer zusätzlich die Instrumente aus Art. 46 DSGVO benötigt werden.
Am 16. April 2024 machte Sentry außerdem seine Datenregion in Deutschland allgemein verfügbar. Sie steht laut Sentry auch Organisationen im kostenlosen Developer-Plan zur Verfügung.
Technisch sieht man die beiden Regionen auch an den API-Domains:
- USA:
us.sentry.io - Deutschland:
de.sentry.io
Sentry dokumentiert beide Endpunkte als unterschiedliche Data Storage Locations. Die Bezeichnung „Datenregion“ braucht allerdings eine Einschränkung. Error-Events, Transaktionen, Spans, Profile, Logs, Metrics und Replays werden am gewählten Standort gespeichert. Sentry dokumentiert aber auch Daten, die unabhängig von dieser Wahl in den USA bleiben können: unter anderem Benutzerkonten, Zugriffs-Tokens, Organisations- und Projektmetadaten sowie Support-Daten.
Bei einer bestehenden SaaS-Organisation kann der gewählte Standort derzeit nicht nachträglich geändert werden. Für einen Wechsel muss man laut Sentry eine neue Organisation anlegen.
Wenn die Anforderung also schlicht „Unsere Error-Events sollen in der EU gespeichert werden“ lautet, hat Hosted Sentry dafür heute eine Lösung. Das war bei der Auswahl eines europäischen Speicherorts lange nicht so eindeutig.
Das EU-US Data Privacy Framework
Auch hier lohnt sich ein aktueller Stand, weil Datenschutzartikel zu US-Diensten schnell altern. Der Angemessenheitsbeschluss für das EU-US Data Privacy Framework ist derzeit gültig. Die Europäische Kommission führte 2024 ihre erste Überprüfung durch und führt den Beschluss weiterhin als geltende Angemessenheitsentscheidung.
Sentry schreibt in seinem aktuellen DPA, dass es das Data Privacy Framework für entsprechende Transfers aus Europa in die USA verwendet. Falls das DPF nicht anwendbar ist oder ungültig werden sollte, sieht das DPA Standardvertragsklauseln als Fallback vor.
Ganz abgeschlossen ist die juristische Geschichte trotzdem nicht. Eine Klage gegen den DPF wurde am 3. September 2025 vom Gericht der Europäischen Union abgewiesen. Gegen dieses Urteil läuft seit dem 31. Oktober 2025 das Rechtsmittel C-703/25 P, Latombe v Commission vor dem Europäischen Gerichtshof. Das Verfahren ist zum Stand September 2026 weiterhin anhängig.
Für eine heutige Architekturentscheidung bedeutet das: Das DPF existiert und kann verwendet werden. Man sollte es aber nicht mit einer Garantie verwechseln, dass sich der europäische Rechtsrahmen für US-Datentransfers nie wieder ändert.
Datenregion und Jurisdiktion
Sentrys deutsche Region löst den Speicherort der ausgewählten Produktdaten. Sie ändert nicht das Unternehmen, mit dem der Kunde den Vertrag schließt.
Im Data Processing Addendum nennt Sentry Functional Software, Inc. d/b/a Sentry in San Francisco, California, als Datenimporteur. Das ist für den US-amerikanischen CLOUD Act entscheidend.
Der CLOUD Act stellt ausdrücklich klar, dass ein Unternehmen, das der US-Gerichtsbarkeit unterliegt, Daten aus possession, custody or control herausgeben können muss, unabhängig davon, wo diese Daten gespeichert werden. Das US Department of Justice formuliert den Punkt selbst so: Ein Unternehmen unter US-Gerichtsbarkeit kann zur Herausgabe von Daten verpflichtet werden, regardless of where it chooses to store that data.
Deshalb gilt für Hosted Sentry: Die deutsche Sentry-Region nimmt die dort gespeicherten Daten nicht aus der Reichweite des CLOUD Act. Ein Serverstandort in Deutschland ändert nicht, dass der Provider Functional Software, Inc. ein US-amerikanisches Unternehmen ist.
Das ist keine Aussage darüber, wie wahrscheinlich eine konkrete Herausgabeanordnung ist. Es ist eine Aussage darüber, wer grundsätzlich rechtlich auf den Provider zugreifen kann.
Hosted Sentry vs. Hosted Bugsink
Wenn man SaaS verwenden möchte, ist Self-Hosting keine besonders hilfreiche Antwort. Man möchte gerade nicht selbst Datenbank-Upgrades durchführen, Backups überwachen, Storage planen und nachts herausfinden, warum der eigene Error Tracker keine Errors mehr trackt.
Deshalb ist der sinnvollere Vergleich Hosted Sentry in der deutschen Region gegen Hosted Bugsink in der EU. Beide nehmen dem Entwicklungsteam den Betrieb des Error Trackers ab. Anwendungen senden Events an einen verwalteten Dienst, der sie verarbeitet, speichert und über eine Weboberfläche zugänglich macht. Der wesentliche Unterschied liegt weniger im Betriebsmodell als in Produktumfang, Anbieter und Jurisdiktion.
Hosted Sentry
Sentry ist inzwischen eine breite Application-Monitoring-Plattform. Der aktuelle Team-Plan umfasst neben Error Monitoring unter anderem:
- Tracing mit 5 Millionen enthaltenen Spans.
- Logs und Application Metrics mit jeweils 5 GB Basisvolumen.
- Session Replay mit einem enthaltenen Kontingent.
- Uptime- und Cron-Monitoring.
- Profiling als zusätzliche Nutzung.
- Seer, Sentrys AI-Debugging-Funktionen (gegen Aufpreis).
Der Team-Plan kostet derzeit €26 pro Monat und enthält 50.000 Error-Events. Zusätzliche Error-Events werden nach Volumen abgerechnet. Die Kontingente und Preise stehen auf Sentrys Pricing-Seite.
Für Teams, die Error Tracking mit Tracing, Logs, Profiling, Replays und weiteren Observability-Funktionen in einem Produkt haben möchten, ist das ein relevanter Vorteil. Aus Datenschutzsicht bietet Sentry:
- Datenregion: Standort in Deutschland.
- DPA: Sentry tritt als Auftragsverarbeiter auf.
- Transfermechanismen: EU-US Data Privacy Framework sowie SCCs als Alternative.
- Datenminimierung: PII-Scrubbing und weitere Einstellungen.
Der Anbieter bleibt dabei Functional Software, Inc. in den USA, wie das DPA festhält. Damit bleibt auch bei Nutzung der deutschen Region der CLOUD Act Teil des juristischen Modells.
Hosted Bugsink
Bugsink ist enger geschnitten. Es ist ein Error Tracker und kein allgemeines Observability-System. Bugsink verarbeitet Error-Events, gruppiert Fehler und zeigt Stacktraces, Source Context, lokale Variablen, Tags und den übrigen Kontext, der zum Debugging einer Exception nötig ist.
Metrics und Traces werden nicht verarbeitet. Das ist in den SDK-Empfehlungen von Bugsink ausdrücklich dokumentiert.
Hosted Bugsink wird von Bugsink B.V. in Utrecht, Niederlande angeboten. Bugsink handelt beim Hosted-Service als Auftragsverarbeiter. Das ist in der Datenschutzerklärung und im DPA festgehalten.
Das DPA ist ziemlich konkret:
- Datenstandort: Alle Hosted-Personendaten werden innerhalb der EU gespeichert und verarbeitet.
- Infrastruktur: Hetzner speichert und verarbeitet die Eventdaten.
- E-Mail: Scaleway wird für transaktionale E-Mails verwendet.
- Zahlungen: Stripe erhält keine Error-Events, Logs oder Applikationsdaten.
- Aufbewahrung: Raw Error-Events werden 60 Tage gespeichert.
Aggregierte und abgeleitete Daten wie Zähler, Tags und first_seen bleiben erhalten, bis der Kunde sie entfernt. Die
Einzelheiten stehen im Bugsink-DPA.
Der entscheidende Unterschied zu Sentry ist dabei nicht der Kontinent des Rechenzentrums. Bugsink B.V. ist ein niederländischer Anbieter und kein US-Unternehmen. Damit fehlt die unmittelbare Anknüpfung an die US-Gerichtsbarkeit, die bei Sentry besteht.
Der CLOUD Act hat nicht plötzlich US-Gerichtsbarkeit über beliebige europäische Provider geschaffen. Er regelt vielmehr, dass Provider, die bereits der US-Gerichtsbarkeit unterliegen, kontrollierte Daten auch dann herausgeben müssen, wenn diese im Ausland gespeichert sind. Das US Department of Justice beschreibt diese Grenze ausdrücklich so.
Bei Sentry besteht diese Anknüpfung unmittelbar: Der Provider ist Functional Software, Inc. Bei Hosted Bugsink besteht diese unmittelbare Anknüpfung nicht: Der Provider ist Bugsink B.V. in den Niederlanden, und die für Applikationsdaten eingesetzten Subprozessoren befinden sich laut DPA ebenfalls in der EU. Das ist der praktische Unterschied zwischen US-SaaS mit deutscher Datenregion und EU-SaaS mit EU-Datenhaltung.
Keine einfache DSGVO-Antwort
Ich würde Sentry deshalb nicht als „nicht DSGVO-konform“ bezeichnen. Das wäre zu einfach und technisch wenig hilfreich. Hosted Sentry kann mit der deutschen Region, seinem DPA, Datenminimierung und den übrigen notwendigen Maßnahmen in einem DSGVO-konformen Setup verwendet werden. Die eigentliche Entscheidung ist granularer.
Wenn eure Anforderung „Die Error-Events müssen in der EU liegen“ lautet, können sowohl Sentry in der deutschen Region als auch Hosted Bugsink diese Anforderung erfüllen. Wer auch Konto-, Organisations- und Support-Daten einschließt, muss Sentrys dokumentierte Ausnahmen für die US-Speicherung mitbewerten.
Wenn eure Anforderung „Der Error-Tracking-Anbieter soll kein US-Unternehmen sein“ lautet, erfüllt Hosted Sentry diese Anforderung nicht. Hosted Bugsink schon.
Wenn eure Anforderung „Ein US-Anbieter soll nicht über den CLOUD Act zur Herausgabe unserer beim Error Tracker gespeicherten Daten verpflichtet werden können“ lautet, löst eine deutsche Sentry-Region das Problem ebenfalls nicht. Hosted Bugsink vermeidet genau diese US-Provider-Anknüpfung.
Datenminimierung bleibt wichtig
Ein europäischer Provider befreit die Anwendung nicht von den normalen Datenschutzanforderungen. Wenn ein Error-Event unnötig Passwörter, Authentication-Header oder komplette Request-Bodies enthält, wird es nicht dadurch zu einer guten Idee, dass der Server in Deutschland steht.
Ich würde bei jedem Hosted Error Tracker mindestens prüfen:
- User Context: Müssen E-Mail-Adresse und Username wirklich mitgesendet werden?
- IP-Adressen: Werden sie benötigt, oder reicht eine interne User-ID?
- Request Headers: Können
Authorization, Cookies oder eigene Tokens auftauchen? - Query-Strings und URLs: Stecken dort IDs, E-Mail-Adressen oder andere Nutzerdaten?
- Lokale Variablen: Welche Daten können im Stackframe landen?
- Retention: Wie lange braucht das Team ein einzelnes Raw Event tatsächlich?
Die beste Kontrolle ist dabei ein echtes Event. Eine Datenschutzerklärung sagt, was theoretisch passieren kann. Ein Event aus der eigenen Anwendung zeigt, was tatsächlich passiert.
Der technische Trade-off
Wenn die Datenschutzanforderungen bei beiden Lösungen erfüllt werden können, bleibt eine normale Produktentscheidung übrig. Sentry und Bugsink haben hier unterschiedliche Ziele. Sentry kombiniert Error Tracking mit einer wachsenden Observability-Plattform. Bugsink konzentriert sich auf Exceptions.
Das bedeutet ganz konkret:
- Wer Tracing, Metrics, Session Replay, Profiling und AI-Debugging im selben Produkt möchte, bekommt bei Sentry mehr.
- Wer hauptsächlich Produktionsfehler mit Stacktrace und Kontext debuggen möchte, nutzt bei Bugsink einen kleineren Funktionsumfang.
- Wer bereits Sentry-SDKs verwendet, muss für Bugsink keine neuen Client-Libraries integrieren.
Bugsink ist mit den Open-Source-SDKs von Sentry kompatibel. Bei einer bestehenden Sentry-Integration besteht der Wechsel für Error Tracking deshalb normalerweise daraus, den DSN auf den Bugsink-Endpunkt zu ändern.
Zum Beispiel bleiben das bestehende Sentry SDK und seine Initialisierung in der Anwendung:
sentry_sdk.init( dsn="https://...@mycompany.bugsink.com/1", )
Nur der DSN verweist jetzt auf Bugsink. Der Wechsel betrifft damit den Endpunkt, nicht die Client-Library.
Preise im Vergleich
Für kleine Projekte haben beide Anbieter kostenlose Einstiegsmöglichkeiten. Sentry enthält im kostenlosen Developer-Plan derzeit 5.000 Error-Events pro Monat für einen Benutzer. Der Team-Plan startet bei €26 pro Monat mit 50.000 Error-Events und unbegrenzten Benutzern. Die weiteren Produktkontingente sind auf Sentrys Pricing-Seite aufgeführt.
Hosted Bugsink startet mit 15.000 Events pro Monat kostenlos, von denen 5.000 gespeichert werden. Die veröffentlichten Paid-Tiers sind derzeit:
- 75.000 Events: €16/Monat.
- 600.000 Events: €50/Monat.
- 3 Millionen Events: €158/Monat.
- 15 Millionen Events: €568/Monat.
- 50 Millionen Events: €1.288/Monat.
Ab dem 75K-Tier sind unbegrenzt viele Benutzer enthalten. Die Pricing-Seite zeigt die Preisstruktur und die verfügbaren Pläne.
Der Preisvergleich ist kein Eins-zu-eins-Vergleich. Sentry verkauft für seinen Basispreis neben Error Tracking auch Tracing, Logs, Metrics und andere Funktionen. Bugsink verkauft im Wesentlichen Error Tracking. Wer diese Sentry-Funktionen tatsächlich nutzt, sollte sie deshalb nicht mit einem Wert von null in den Vergleich einsetzen. Wer sie nicht nutzt, bezahlt allerdings trotzdem für eine wesentlich breitere Plattform.
Welche Hosted-Variante passt?
Wenn ein Team bereits Sentry verwendet, die breite Plattform nutzt und lediglich sicherstellen möchte, dass seine Error-Events in der EU gespeichert werden, würde ich zuerst Sentrys deutsche Region prüfen. Dafür muss man keinen neuen Error Tracker einführen.
Wenn die Anforderung dagegen lautet, dass auch der Provider selbst europäisch sein soll, ist das eine andere Architekturentscheidung. Dann ist eine deutsche Region eines US-Anbieters nicht äquivalent zu einem europäischen SaaS-Anbieter. Genau dafür gibt es Hosted Bugsink.
Ich baue Bugsink, deshalb ist das hier offensichtlich keine unabhängige Produktempfehlung. Der technische Vorschlag ist trotzdem einfach zu testen: Wenn eure Anwendungen bereits Sentry-SDKs verwenden, legt ein Bugsink-Projekt an, tauscht den DSN aus und sendet echte Test-Events. Dann könnt ihr anhand des tatsächlichen Workflows entscheiden, ob ihr die zusätzlichen Observability-Funktionen von Sentry braucht oder ob Error Tracking allein für diesen Teil eures Stacks reicht.
Aus Datenschutzsicht ist der Unterschied dabei klar. Sentry DE speichert die ausgewählten Produktdaten in Europa, aber bestimmte Metadaten können in den USA bleiben. Der Provider bleibt ein US-Unternehmen und CLOUD-Act-Adressat. Hosted Bugsink speichert und verarbeitet die Applikationsdaten in der EU bei einem niederländischen Provider. Anders als bei Sentry besteht keine unmittelbare Anknüpfung an die US-Gerichtsbarkeit. Für Teams, deren Anforderung genau das ist, ist das kein Marketingunterschied, sondern eine andere Provider-Architektur.
Self-Hosting
Beide Produkte lassen sich grundsätzlich auch selbst betreiben. Für jemanden, der gezielt nach einer Hosted-Datenschutzlösung sucht, ist das aber eine andere Entscheidung: Dann übernimmt das eigene Team Betrieb, Updates, Backups und Verfügbarkeit des Error Trackers.
Bei Bugsink ist Self-Hosting ein regulär unterstütztes Betriebsmodell. Bei Sentry existiert ebenfalls eine Self-Hosted-Version, die jedoch deutlich mehr Infrastruktur mitbringt.
Für den Vergleich auf dieser Seite ist das nicht entscheidend. Hier geht es um zwei SaaS-Varianten: Hosted Sentry mit deutscher Datenregion und Hosted Bugsink als europäischer Anbieter.
Hosted Bugsink ausprobieren
Wenn die europäische Provider-Architektur zu euren Anforderungen passt, könnt ihr Hosted Bugsink kostenlos mit 15.000 Events pro Monat ausprobieren. Auf der Pricing-Seite könnt ihr vorher die weiteren Event-Volumen und Preise vergleichen.