Die meisten Fehler in einer Produktivumgebung meldet niemand. Nutzerinnen und Nutzer laden die Seite neu, versuchen es später erneut oder brechen ab. Was im Team ankommt, ist bestenfalls ein Bruchteil, oft erst Tage später als vage Beschreibung: „Bei mir ging das gestern nicht."
Damit fehlt die Grundlage für jede Priorisierung. Ob ein Fehler einmal aufgetreten ist oder vierhundertmal, seit dem letzten Release besteht oder schon länger, alle Nutzenden betrifft oder eine Randbedingung — all das bleibt Vermutung, solange niemand mitschreibt.
Error Tracking löst dieses Problem seit Langem. Der Aufwand liegt selten im Werkzeug selbst, sondern in seiner Einrichtung: Projekt anlegen, SDK einbinden, Release-Informationen durchreichen, Zugänge verteilen — genau diesen Teil übernimmt die Plattform.
Sentry wird vollständig eingerichtet
Die Plattform setzt Sentry für dein Projekt auf. Du musst die Anbindung nicht selbst zusammenstecken und nicht in jedem neuen Projekt wiederholen. Eine Bedingung gibt es: Sentry wird nur eingerichtet, wenn im Projekt eine eigene Sentry-Anbindung hinterlegt ist — die Fehlerdaten liegen damit in deiner Organisation, nicht in einem geteilten Sammelkonto. Das Formular kennt zusätzlich einen Host-Modus für selbst betriebene Instanzen.
Fehler erscheinen dort, wo du ohnehin arbeitest
Produktionsfehler siehst du direkt in der Plattform, gefiltert nach Repository. Zu jedem Eintrag gehören Stacktrace, Release und Kontext — die Angaben, mit denen sich ein Fehler nachvollziehen lässt, statt ihn erst reproduzieren zu müssen.
Für die tiefere Analyse führt ein Verweis in die Detailansicht in Sentry — eine bewusste Entscheidung, nicht der einzige Weg, überhaupt zu erfahren, dass etwas nicht funktioniert.
Der Filter nach Repository ist mehr als eine Bequemlichkeit: Bei mehreren Anwendungen in derselben Organisation siehst du nur die Fehler des Projekts, an dem du gerade arbeitest, statt einer gemeinsamen Liste.
Anmeldung über Single Sign-on
Sentry-Anbindungen erhalten automatisch Single Sign-on über Authentik. Das Team meldet sich mit dem Plattform-Login an, ohne separate Zugänge anzulegen, zu verteilen und beim Ausscheiden zu entfernen. Im Profil führt ein Verweis direkt zur Anmeldeseite der eigenen Sentry-Organisation.
Versionierte Releases machen Fehler zuordenbar
Releases sind versioniert, und diese Version steht am Fehler. Aus der Frage „Wann hat das angefangen?" wird eine Frage mit Antwort: Tritt ein Fehler erst ab einer bestimmten Version auf, grenzt das die Ursache auf die Änderungen dieses Releases ein — statt auf Wochen. Umgekehrt gilt das genauso: Tritt ein Fehler nach einem Release nicht mehr auf, ist die Behebung nachweisbar, nicht nur wahrscheinlich.
Monitoring ergänzt das Bild
Auf dem Projekt-Dashboard erscheinen zusätzlich Monitoring-Daten der Server live, sodass Anwendungsfehler und Serverzustand nebeneinander stehen. Das hilft bei der Einordnung: Eine Häufung von Fehlern kurz nach einem Release deutet auf die Änderung hin, dieselbe Häufung bei auffälligen Serverwerten eher auf die Infrastruktur.
Verwandte Themen
Dass Sentry ohne manuelle Einrichtung bereitsteht, folgt demselben Prinzip wie der Rest der Plattform: wiederkehrende Aufbauarbeit wird einmal automatisiert statt in jedem Projekt neu erledigt. Wie das für Build und Auslieferung aussieht, beschreibt die Seite zur CI/CD-Automatisierung. Welche weiteren Dienste sich anbinden lassen, steht in der Übersicht der Funktionen.
