Error Tracking 2026: Sentry-Alternativen und der Self-Hosted-Kompromiss

Sentry wurde aus gutem Grund zum Standard-Error-Tracker: exzellente Stacktraces, ausgereifte SDKs und Release-Tracking, das Regressionen erkennt, bevor deine Nutzer dir E-Mails schreiben. Zwei Kräfte treiben mittelgroße SaaS-Teams 2026 trotzdem zu Sentry-Alternativen: die Rechnung, die schneller wächst als das Geschäft, und EU-Datenresidenz-Anforderungen, die aus "schick es einfach an einen US-Anbieter" ein Gespräch mit dem Datenschutzbeauftragten statt einer Konfigurationszeile machen.

Dieser Beitrag geht die realistische Auswahl durch: Sentry Managed, Sentry Self-Hosted, GlitchTip, Highlight.io und Rollbar. Für jede Option betrachten wir Einrichtungsaufwand, Alerting-Qualität, Source-Map-Unterstützung für Next.js, Qualität des PHP-SDKs, Datenresidenz und den Kostenverlauf bei wachsendem Event-Volumen. Am Ende stehen eine Entscheidungsmatrix und die Konfiguration, die wir standardmäßig für Symfony- und Next.js-Projekte einsetzen.

Warum Teams 2026 nach Sentry-Alternativen suchen

Drei Auslöser tauchen in fast jedem Gespräch auf, das wir über Error Tracking führen:

Preis bei Skalierung. Die Managed-Pläne von Sentry werden pro Event abgerechnet, und eine einzige fehlerhafte Schleife oder eine Bot-Welle kann ein Monatskontingent in Stunden aufbrauchen. Spike Protection und Rate Limits helfen, aber Teams mit 5 bis 10 Millionen Events pro Monat stellen regelmäßig fest, dass Error Tracking in dieselbe Budgetzeile rutscht wie ihre primäre Datenbank. Die Kosten sind nicht falsch, sie sind nur höher, als die meisten Teams erwartet haben, als sie das SDK im ersten Jahr eingebaut haben.

Datenresidenz. Sentry bietet eine EU-Datenregion an, was die Frage nach dem Speicherort löst. Was sie allein nicht löst, ist die Anbieterfrage: Ein Unternehmen mit US-Hauptsitz, das personenbezogene Daten aus der EU verarbeitet, braucht in den meisten Compliance-Frameworks weiterhin einen Auftragsverarbeitungsvertrag, Standardvertragsklauseln und ein Transfer Impact Assessment. Error-Payloads sind häufiger personenbezogene Daten, als Teams annehmen. Request Bodies, User-IDs, IP-Adressen und Cookies landen alle im Error-Kontext, wenn du sie nicht aktiv entfernst.

Operativer Appetit. Manche Teams haben Platform Engineers, die gerne Infrastruktur betreiben. Die meisten nicht. Die Self-Hosted-Frage lautet weniger "können wir das?" und mehr "wer patcht es in Monat acht, wenn die Person, die es aufgesetzt hat, andere Prioritäten hat?"

Wenn du unsicher bist, welcher Auslöser auf dich zutrifft, ist das selbst ein Signal, deine Anforderungen aufzuschreiben, bevor du irgendein Tool anfasst. Unser Service zur Tech-Stack-Strategie existiert genau für Entscheidungen wie diese.

Sentry Managed: Immer noch die Messlatte

Managed Sentry bleibt die Option, an der jede Alternative gemessen wird.

• Einrichtungsaufwand: Minimal. SDK installieren, DSN setzen, an einem Nachmittag erledigt, inklusive Source Maps.
• Alerting: Best in Class. Issue-Gruppierung, Regressionserkennung gekoppelt an Releases, Metrik-Alerts und ausgereifte Integrationen für Slack und PagerDuty.
• Next.js Source Maps: First-Party-Unterstützung über @sentry/nextjs, inklusive automatischem Upload während des Builds. Das ist die stärkste Source-Map-Story aller Tools in dieser Liste.
• PHP-SDK: Das offizielle Bundle sentry/sentry-symfony wird gut gepflegt, integriert sich mit Monolog und erfasst Messenger-Fehler out of the box.
• Datenresidenz: EU-Datenregion verfügbar. Die Anbieterbeziehung braucht trotzdem die oben erwähnten Compliance-Unterlagen.
• Kosten bei Volumen: Der Schmerzpunkt. Preisgestaltung pro Event bedeutet, dass die Kosten linear mit dem Traffic und mit der Geschwätzigkeit deines Codes skalieren. Aggressives Sampling und Inbound-Filter sind Pflichthygiene, kein optionales Tuning.

Fazit: Wenn dein Event-Volumen moderat ist und dein Compliance-Team mit EU-Region plus Standardvertragsklauseln zufrieden ist, ist der Verbleib bei Managed Sentry oft die richtige, langweilige Antwort.

Sentry Self-Hosted: Die wahren Betriebskosten

Self-Hosted Sentry ist kostenlos im Sinne der Lizenz, nicht im Sinne des Aufwands. Der Stack hinter einer modernen Sentry-Installation ist beachtlich: Postgres, Kafka, ClickHouse, Redis, Symbolicator und eine Flotte von Workern, alles orchestriert über ein großes Docker-Compose-Setup.

Was das in der Praxis bedeutet:

• Einrichtungsaufwand: Ein Wochenende, wenn alles gut läuft. Das Installationsskript funktioniert, aber zu verstehen, was es installiert hat, dauert länger.
• Hardware: Plane eine dedizierte Maschine mit 16 GB RAM als realistische Untergrenze ein, plus Storage, der mit der Aufbewahrungsdauer wächst. Bei Millionen Events pro Monat wird der ClickHouse-Speicherverbrauch zu einem Posten, den du überwachst.
• Update-Last: Das sind die Kosten, die Teams unterschätzen. Sentry liefert schnell aus, und Self-Hosted-Upgrades beinhalten gelegentlich Migrationsschritte, die sorgfältiges Lesen der Release Notes erfordern. Mehrere Versionen zu überspringen und dann zu aktualisieren ist der Ort, an dem Wochenenden sterben.
• Feature-Parität: Gut, mit Verzögerung. Manche Features der Managed-Plattform kommen spät oder gar nicht.
• Datenresidenz: Perfekt, per Definition. Die Daten verlassen deine Infrastruktur nie, was jedes Compliance-Gespräch verkürzt.

Die ehrliche Einordnung: Self-Hosted Sentry verwandelt ein planbares Abo in eine unplanbare Engineering-Steuer. Für Teams mit echter Plattform-Kapazität und harten Residenz-Anforderungen ist das ein fairer Tausch. Für ein Team aus acht Produktentwicklern meist nicht.

GlitchTip: Die unterschätzte Alternative

GlitchTip reimplementiert die Sentry-API mit einem Bruchteil des operativen Fußabdrucks: Django, Postgres, Redis und ein Worker. Das ist der ganze Stack.

• Einrichtungsaufwand: Ein bis zwei Stunden. Ein kleines Docker-Compose-File, kein Kafka, kein ClickHouse.
• SDK-Kompatibilität: Das ist das Killer-Feature. GlitchTip akzeptiert Events von offiziellen Sentry-SDKs. Dein Setup mit sentry/sentry-symfony und @sentry/nextjs funktioniert weiter; du änderst nur den DSN.
• Alerting: Funktional, aber einfach. E-Mail- und Webhook-Benachrichtigungen decken das Wesentliche ab. Du verzichtest auf die Release-gekoppelte Regressionserkennung von Sentry und dessen reichere Gruppierungslogik.
• Next.js Source Maps: Unterstützt über den Sentry-CLI-Upload-Pfad, mit gelegentlichen Kanten. Plane hier etwas Debugging-Zeit ein.
• Datenresidenz: Wie bei jeder Self-Hosted-Option: deine Server, deine Regeln. GlitchTip bietet außerdem eine gehostete Version mit EU-Hosting, falls du die Residenz-Story ohne den Betriebsaufwand willst.
• Kosten: Ein kleiner VPS betreibt es für die meisten mittleren Workloads bequem. Bei 10 Millionen Events pro Monat zahlst du für einen bescheidenen Server und etwas Storage, nicht für eine Rechnung pro Event.

Fazit: Für Teams, deren Hauptanforderungen "Fehler fangen, sinnvoll gruppieren, uns alarmieren, in der EU bleiben, kein Vermögen kosten" lauten, deckt GlitchTip einen überraschend großen Teil des Sentry-Werts mit einem Zehntel des operativen Gewichts ab.

Highlight.io und Rollbar: Die Spezialisten

Highlight.io bündelt Session Replay, Error Tracking und Logging in einem Open-Source-Produkt. Wenn dein Debugging-Schmerz "was hat der Nutzer vor dieser Exception eigentlich getan?" lautet, ist Replay verknüpft mit dem Fehler ein echter Fortschritt gegenüber Stacktraces allein. Die Kompromisse: ein schwererer Self-Hosted-Stack als GlitchTip (es will ebenfalls ClickHouse und Kafka), eine jüngere PHP-Story als das Sentry-Ökosystem und ein Frontend-lastiger Schwerpunkt. Am stärksten passt es für Teams, deren kritische Fehler im Browser leben.

Rollbar bleibt relevant, besonders für PHP-lastige Teams. Sein PHP-SDK ist ausgereift, seine Gruppierungs-Engine ist gut, und die Abrechnung pro Occurrence kann Sentry bei bestimmten Volumenprofilen unterbieten. Es ist ein Managed-Anbieter aus den USA, das Compliance-Gespräch ähnelt also dem von Sentry, und sein Momentum im Next.js-Ökosystem liegt hinter dem von Sentry. Ziehe es in Betracht, wenn du ältere PHP-Anwendungen konsolidierst und einen bewährten, unaufgeregten Tracker willst. Wenn diese älteren Anwendungen Teil eines größeren Aufräumens sind, ist das meist ebenso sehr ein Gespräch über Legacy-Code-Optimierung wie über Tooling.

Entscheidungsmatrix

	Setup	Alerting	Next.js Source Maps	PHP-SDK	EU-Residenz	Kosten bei ~10M Events/Monat
Sentry Managed	Trivial	Exzellent	Exzellent	Exzellent	EU-Region + AVV/SCCs	Hoch, pro Event
Sentry Self-Hosted	Schwer	Exzellent	Exzellent	Exzellent	Volle Kontrolle	Server + echte Ops-Zeit
GlitchTip	Leicht	Einfach	Gut, etwas Reibung	Exzellent (Sentry-SDK)	Volle Kontrolle oder EU-gehostet	Ein kleiner Server
Highlight.io	Schwer	Gut	Gut	Jung	Volle Kontrolle	Mittelgroßer Server-Stack
Rollbar	Trivial	Gut	Ausreichend	Ausgereift	US-Anbieter, Papierkram	Moderat, pro Occurrence

Drei ehrliche Defaults fallen aus dieser Tabelle heraus. Wenn Kosten und Compliance nicht wirklich wehtun, bleib bei Managed Sentry. Wenn Residenz hart gefordert ist und Ops-Kapazität real vorhanden, hoste Sentry selbst. Wenn du 80 Prozent des Werts mit 10 Prozent der operativen Fläche willst, betreibe GlitchTip mit den offiziellen Sentry-SDKs.

Was wir für Symfony- und Next.js-Projekte einsetzen

Für die meisten Kundenprojekte setzt Wolf-Tech standardmäßig auf das GlitchTip-kompatible Setup mit einer Ausstiegsluke:

1. Instrumentiere mit offiziellen Sentry-SDKs auf beiden Seiten: sentry/sentry-symfony mit Monolog- und Messenger-Integration im Backend, @sentry/nextjs mit Source-Map-Upload zur Build-Zeit im Frontend.
2. Richte den DSN auf GlitchTip (self-hosted auf EU-Infrastruktur, oder der EU-gehostete Plan von GlitchTip für Teams ohne Ops-Kapazität).
3. Bereinige aggressiv auf SDK-Ebene: before_send-Hooks entfernen Request Bodies, Cookies und alles, was nach personenbezogenen Daten aussieht, bevor Events die Anwendung verlassen.
4. Halte den DSN über Environment-Konfiguration austauschbar, damit ein späterer Wechsel zu Managed Sentry eine Ein-Zeilen-Änderung ist, keine Migration.

Dieses Setup hält die Compliance-Fläche klein, die Rechnung planbar und die SDK-Schicht identisch zu dem, was jedes zukünftige Teammitglied bereits kennt. Die Qualität des Error Trackings ist letztlich eine Frage der Codequalität: Ein Tracker hilft nur, wenn jemand ihn triagiert, und eine Codebasis, die 10 Millionen verrauschte Events pro Monat produziert, hat ein Problem, das kein Dashboard löst. Diese Triage-Disziplin bauen wir regelmäßig über unser Code-Quality-Consulting in Teams auf, und die Verkabelung des gesamten Stacks in einem neuen Build ist Standardumfang unserer Arbeit in der individuellen Softwareentwicklung.

Ohne Reue entscheiden

Der falsche Weg, einen Error Tracker auszuwählen, ist die Feature-Liste. Der richtige Weg führt über die Randbedingungen: Wie hoch ist dein reales Event-Volumen? Ist EU-Residenz eine rechtliche Anforderung oder eine Präferenz? Wer besitzt den Tracker in Monat acht? Beantworte diese drei Fragen, und die Matrix oben kollabiert meist auf eine offensichtliche Zeile.

Wenn du eine zweite Meinung zu deinem Observability-Stack möchtest oder Hilfe beim Umzug weg von einem Tracker, der zum Budgetproblem geworden ist, schreib an hello@wolf-tech.io oder besuche wolf-tech.io. Wir haben das oft genug aufgesetzt, um zu wissen, wo die scharfen Kanten sind.