Die meisten Produktionsfehler meldet niemand. Nutzer laden neu und gehen weiter. Was im Team ankommt, ist ein Bruchteil, oft Tage später: „Gestern ging das nicht.“
Ob das einmal passiert ist oder vierhundertmal seit dem letzten Release, bleibt Vermutung – solange niemand mitschreibt. Sentry kann das. Der Aufwand liegt selten im Werkzeug, sondern in der Einrichtung. Genau den Teil übernimmt die Plattform.
Sentry nach der Anbindung
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 in der Sentry-Organisation
Nach der Sentry-Anbindung richtet die Plattform Single Sign-on in diese Sentry-Organisation ein. Das Team meldet sich dort mit dem bestehenden Plattform-Konto an (E-Mail und Passwort oder Passkey). Das ist kein dritter Anmeldeweg an der Plattform selbst und kein von der Plattform gehostetes Sentry. 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 folgt
Infrastruktur-Monitoring ist angekündigt, aber noch nicht der Betriebsstandard. Error-Tracking mit Sentry ist der aktuelle Kanal für Anwendungsfehler. Serverzustand und Monitoring-Daten auf dem Dashboard folgen.
Verwandte Themen
Sobald die Sentry-Anbindung steht, übernimmt die Plattform die restliche Einrichtung. 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.
