App-Abstürze nach dem Launch überwachen: ein Plan für Produktteams

Die App läuft, aber das Ticket fehlt

An der Zugangssperre öffnet eine Reisende ihr mobiles Ticket. Die App schließt sich, bevor der Code erscheint. Im Test war dieser Weg erfolgreich. Für die Person am Bahnsteig zählt jedoch nur, ob sie jetzt weiterkommt. Die Szene im Titelbild ist ein Beispiel, kein dokumentierter Vorfall bei einem Appfyl-Kunden.

Nach einem Release sollten Sie drei Fragen beantworten können: Wer konnte welche Aufgabe nicht abschließen, in welcher Version trat das Problem auf und wer kümmert sich darum? Die Checkliste für den App-Launch bereitet die Veröffentlichung vor. Hier geht es um den Betrieb danach, wenn reale Geräte und Nutzungsweisen dazukommen.

Nicht jeder Fehler ist ein Absturz

Bei einem Absturz beendet sich die App unerwartet. Ein ANR unter Android bedeutet, dass sie nicht mehr auf Eingaben reagiert. Und manchmal bleibt sie offen, bestätigt eine Buchung auf dem Bildschirm, speichert diese aber nie auf dem Server. Wer nur die Zahl der Abstürze betrachtet, übersieht genau solche stillen Fehler.

Firebase unterscheidet absturzfreie Nutzer und Sitzungen. Beide Kennzahlen beziehen sich auf schwerwiegende Fehler, nicht auf alle gescheiterten Geschäftsvorgänge. Ein guter Durchschnitt kann verdecken, dass etwa gerade zahlende Mitglieder den Zugang nicht nutzen können.

Einen leeren Bericht erst einmal anzweifeln

Lassen Sie sich vor dem Launch einen absichtlich ausgelösten Testabsturz aus einem produktionsnahen Build zeigen, einschließlich des Eintrags im Fehlerdienst. Sind App-Version, Plattform, Gerät und lesbare Fehlerstelle vorhanden? Ohne passende Symbol-Dateien für iOS oder Zuordnungsdateien für Android lässt sich ein gemeldeter Absturz häufig schwer einordnen. Nach Änderungen an der Build-Pipeline sollte diese Probe wiederholt werden.

Ebenso wichtig ist der Weg der Warnung. Wer erhält sie, wer übernimmt bei Abwesenheit und wer darf den Release anhalten? Laut Firebase-Dokumentation erfordern manche Warnungen, etwa für neue schwerwiegende Fehler und ANRs, eine bewusste Konfiguration des Benachrichtigungskanals. Eine Meldung in einem Konto, das niemand öffnet, ist keine Überwachung.

Protokollieren Sie nur den nötigen Kontext: Version, anonymisierte Fehlerkennung und einen unkritischen vorherigen Schritt. Passwörter, Token, Zahlungsdetails und sensible Nachrichten gehören nicht in Fehlerberichte. Prüfen Sie bei einem neuen SDK auch die Angaben in der Datenschutzerklärung.

Mehrere Sichten, eine verantwortliche Person

Android vitals zeigt Stabilitätssignale aus Google Play. Crashlytics gruppiert Fehler und unterstützt den Vergleich von Versionen. Sentry ist eine mögliche Alternative, wenn zusätzlich Fehler- und Leistungsdaten über mehrere Systeme benötigt werden. Keines dieser Werkzeuge allein beweist, dass eine Zahlung verbucht wurde oder ein Termin im Verwaltungssystem steht.

Für die Produktverantwortung reicht ein überschaubarer Blick: Wie weit ist die neue Version verbreitet? Welche Probleme sind neu oder wieder da? Wie viele Menschen sind betroffen und welche Aufgabe misslingt? Das Release Monitoring von Firebase kann aktuelle und vorige Versionen gegenüberstellen. Ergänzen Sie es um die Ereignisse aus dem App-Analytics-Plan, damit ein Einbruch bei erfolgreichen Check-ins sichtbar wird, auch wenn die Absturzzahl gleich bleibt.

Wann ein Release gestoppt werden sollte

In einem Fitnessstudio beginnt ein Kurs, die App startet normal, aber der Check-in kommt nicht an. Das Personal lässt Mitglieder schließlich von Hand hinein. Hier ist eine sichere Zwischenlösung für Zugang und Anwesenheitsliste wichtiger als eine unauffällige Absturzquote.

Vereinbaren Sie vorher, welche Fälle sofort eine Entscheidung auslösen: neue massenhafte Abstürze, blockierte Anmeldung oder Zahlung, verlorene Einträge sowie Sicherheits- oder Datenschutzprobleme. Ein kleiner Darstellungsfehler kann meist auf das nächste Update warten. Entscheidend sind Schwere, Zahl der Betroffenen, betroffene Version und die Frage, ob ein zentraler Ablauf stillsteht. Eine pauschale Prozentgrenze passt nicht gleichermaßen zu einer Ticket-App und einer Freizeit-App.

Bei einem gestaffelten Rollout können Sie die Ausweitung anhalten, während Entwicklung und Support reagieren. Das macht bereits veränderte Backend-Daten nicht rückgängig; dafür braucht es einen eigenen Wiederherstellungsplan. Der Vorfall sollte später als Testfall in die Qualitätsprüfung vor dem nächsten Start eingehen.

Die ersten Stunden nach Veröffentlichung

Bestimmen Sie vorab einen Beobachtungszeitraum, einen Ersatz für die verantwortliche Person und die wenigen Vorgänge, die auf keinen Fall ausfallen dürfen. Prüfen Sie nach Freigabe zuerst, ob die neue Version überhaupt Sitzungen meldet. Ein leeres Diagramm ohne aktive Nutzer ist keine Entwarnung. Vergleichen Sie mit dem alten Build, testen Sie den wichtigsten Ablauf auf einem echten Gerät und prüfen Sie das Ergebnis auch im Backend oder in der Produktanalyse. Wiederholen Sie die Kontrolle, wenn weitere Geräte und Betriebssysteme die Version nutzen.

Bei einem Problem halten Sie betroffene Version, Kundenweg, Zwischenlösung, zuständige Person und nächsten Prüftermin fest. Nach einem Fix zählt nicht der abgeschlossene Programmierauftrag, sondern ob die veröffentlichte Version wieder funktioniert und der Fehler nicht erneut auftritt. Das gehört zur laufenden App-Wartung.

Warten Sie mit der Information an den Support nicht auf die vollständige Fehlerursache. Schon die Aussage „Der Check-in dieser Version kann fehlschlagen; wir erfassen Besuche vorübergehend an der Rezeption“ hilft mehr als ein allgemeiner Hinweis auf technische Schwierigkeiten. Halten Sie fest, wer die nachgetragenen Einträge später mit dem System abgleicht. Sonst ist der Bildschirm repariert, aber die Anwesenheitsliste bleibt unvollständig.

Wenn Sie eine instabile App an ein neues Team übergeben, helfen Store-Links, Versionsnummer, ein konkreter fehlgeschlagener Ablauf und Zugriff auf vorhandene Fehlerberichte mehr als die Bitte, sie „stabil zu machen“. Appfyl kann diese Angaben über einen kurzen Projektfragebogen aufnehmen und danach einschätzen, ob eine gezielte Reparatur oder eine größere Überarbeitung nötig ist. Die Ursache lässt sich ohne Untersuchung nicht seriös versprechen.

Häufige Fragen