Alle Fallstudien

Fallstudie

3.338 Fehler in 30 Tagen. Neun von zehn lösten keine Fehlermeldung aus.

AdaptlyPost

SaaS für Social-Media-Planung und -Veröffentlichung

13. Juli bis 13. August 2026

Die AdaptlyPost-Startseite

75.167

analysierte Aufzeichnungen

13. Juli bis 13. August 2026

3.338

echte Fehler

4,4 % von allem Analysierten

66

verschiedene Ursachen

1 kritisch, 7 hoch, 15 mittel, 43 niedrig

90 %

ohne Fehlermeldung

3.019 von 3.338 ohne Konsolen- oder Netzwerkfehler

Kurz gefasst

Flowsery analysierte in einem Monat 75.167 Session-Aufzeichnungen von adaptlypost.com und fand 3.338 echte Fehler aus 66 verschiedenen Ursachen. Neun von zehn dieser Fehler lösten keinen Konsolen- oder Netzwerkfehler aus, und Sessions, die einen Fehler trugen, waren in 2,8 % der Fälle ein echtes Versagen. Es folgen vier Befunde, sortiert nach dem, was sie kosten, nicht danach, wie oft sie auftraten.

Zwischen dem 13. Juli und dem 13. August 2026 analysierte Flowsery 75.167 Session-Aufzeichnungen von adaptlypost.com und markierte 3.338 davon als echtes Versagen für den Besucher. Die Gruppierung nach Ursache fasste sie zu 66 verschiedenen Bugs zusammen: einer kritisch, sieben hoch, fünfzehn mittel, dreiundvierzig niedrig.

3.019 der 3.338 Fehler trugen weder einen Konsolenfehler noch einen Netzwerkfehler. Neun von zehn. Im selben Monat trugen 11.598 Sessions einen Fehler, und 319 davon waren ein echtes Versagen. Ein Error-Monitor hätte bei den falschen elftausend Sessions Alarm geschlagen und die dreitausend verschlafen, auf die es ankam.

Die vier Befunde unten sind nach Kosten sortiert, nicht danach, wie oft sie auftraten.

Über AdaptlyPost

AdaptlyPost ist ein Social-Media-Scheduler, der mit einem 7-Tage-Test verkauft wird. Er erscheint in fünf Sprachen und hat einen Blog mit einem Glossar, das Google indexiert. AdaptlyPost und Flowsery haben denselben Gründer.

Die AdaptlyPost-Startseite
Die AdaptlyPost-Startseite.

Wie die Studie ablief

Die Session-Aufzeichnung lief auf der Website etwa zwei Monate, bevor die KI-Analyse am 13. Juli 2026 eingeschaltet wurde. Diese Studie deckt genau einen Monat ab diesem Datum ab. Die 75.167 Aufzeichnungen sind dieser Rückstand plus alles, was der Live-Traffic produzierte, während die Pipeline lief.

Eine Aufzeichnung zählt als Fehler, wenn der Besucher etwas versucht hat, das die Seite anbot, und die Seite es nicht geliefert hat. Eine Kartenablehnung ist kein Fehler, weil ein Nein der Bank kein Bug ist. Ein Zahlungsbutton, der beim Klick nichts tut, ist einer. Jeder Fehler trägt einen Schweregrad, Reproduktionsschritte und einen Link zur Aufzeichnung. Fehler mit derselben Ursache werden gruppiert, und so wurden aus 3.338 dann 66.

Von Aufzeichnungen zu Ursachen
Analysierte Aufzeichnungen75.167
Echte Fehler3.338 · 4,4 %
Verschiedene Ursachen66
66 Ursachen nach Schweregrad
1 kritisch7 hoch15 mittel43 niedrig
Die Gruppierung nach Ursache macht aus 3.338 Sessions 66 Einträge.

Befund 1: der Checkout blockierte Zahlungen auf fünf verschiedene Arten

Sieben Sessions im Zeitfenster endeten damit, dass die Website selbst eine Zahlung stoppte, auf fünf getrennte Arten.

Was Besucher beim Bezahlschritt sahen
1
Ein Serverfehler auf dem Test-Button. In der portugiesischen Sprachversion klickt der Besucher "start free trial", und die Anfrage scheitert auf dem Server. Auf dem Bildschirm erscheint nichts Brauchbares. Vier Versuche, dann geht er.
2
"Internal server error" bei Start Free Trial. Der Besucher versucht es erneut, wechselt den Abrechnungszeitraum, probiert stattdessen PayPal und kommt nie zurück.
3
Ein toter PayPal-Button. Rechnungsdaten ausgefüllt, schnelle Klicks auf "Pay with PayPal", keine Reaktion, Session vorbei.
4
Ein Upgrade, von einer Billing-Regel abgewiesen. Ein Bestandskunde will in einen größeren Plan wechseln und bekommt "Payment Failed", weil das Abosystem das Startdatum eines bereits abgerechneten Plans nicht ändert. Fünf Sessions. Die längste besteht aus 34 Minuten, in denen das Zahlungs-Overlay immer wieder geöffnet und geklickt wird, bevor der Kunde aufgibt.
5
Ein 404er auf der Upgrade-Seite. In einer Sprachversion existierte die Upgrade-Route nicht. Der Besucher irrt über Home, Dashboard und Billing, findet nie einen Weg, mehr zu zahlen, und geht.
Die zitierten Texte sind das, was auf dem Bildschirm des Besuchers stand.

Zwei der fünf, die Serverfehler, würden in einem Error-Tracker auftauchen. Die Billing-Regel ist das Zahlungssystem, das genau wie vorgesehen funktioniert und einen Kunden abweist, der mehr zahlen will. Der tote PayPal-Button wirft überhaupt nichts. Die fehlende Upgrade-Seite ist ein 404er, und 404er sind auf jeder Website Hintergrundrauschen.

Das eine kritische Problem lag auf der französischen Anmeldeseite. Ein Besucher schickte das Formular ab, und die Seite zeigte "400: Bad Request", sehr wahrscheinlich weil das Bot-Check-Widget nie gerendert wurde. Er ging. Ein Anmeldeformular sollte "Ungültige E-Mail oder Passwort" sagen, keinen HTTP-Status zeigen.

Befund 2: ein Control schluckte Klicks auf 17 Routen

48 Sessions über 17 verschiedene Routen zeigen dasselbe Muster. Ein Besucher klickt einen Selector, sichtbar passiert nichts, er klickt erneut, und noch einmal, und dann geht er.

Es ist eine einzige Komponente, wiederverwendet auf jeder Seite, die den Besucher etwas auswählen lässt.

  • Im deutschen Post-Editor öffnet ein angemeldeter Kunde die Pinterest-Einstellungen und klickt wiederholt auf "Board auswählen". Das Dropdown geht nie auf. Er klickt trotzdem auf "Jetzt posten". Der Post geht nie raus.
  • Im AI-Post-Generator bringt "Select Platform" über wiederholte Klicks hinweg keine Reaktion. Der Besucher gibt auf und klickt auf den Seitentitel.
  • Im Influencer-Rate-Rechner ignoriert der Button für die Engagement-Stufe sechs Sekunden hartes Klicken, bevor er endlich reagiert.
  • Im Username-Availability-Checker bewirken drei Klicks auf die Plattformliste nichts. Der Besucher erreicht "Check Availability" nie.

Nichts davon wirft eine Exception. Jedes Mal feuert ein Click-Handler in eine Komponente, deren visueller Zustand sich nie aktualisiert, sodass der Besucher "ignoriert" nicht von "kaputt" unterscheiden kann. Rage Clicks sind das einzige Signal, und dieses Signal existiert nur in einer Aufzeichnung.

Ein Selector, ein Besucher, sechs Sekunden
0 s6 s
10Klicks
0Änderungen auf dem Bildschirm
0protokollierte Fehler
Zehn Klicks in sechs Sekunden auf den Engagement-Stufen-Selector des Influencer-Rate-Rechners. Auf dem Bildschirm änderte sich nichts, und protokolliert wurde nichts.

Befund 3: die Übersetzungen, die nicht geladen wurden

AdaptlyPost veröffentlicht in fünf Sprachen, und die Nähte sind sichtbar. Neun Sessions im Zeitfenster, auf vier Routen, endeten damit, dass der Besucher etwas ansah, das nie als Text gedacht war: einen Übersetzungsschlüssel, eine Fehlerseite in der falschen Sprache oder einen Platzhalter.

Was der Besucher sahSessionsWoFehlersignal
Übersetzungsschlüssel als Seitentext5/en/media-kitKeines
Eine 500-Seite nach dem Sprachwechsel2StartseiteHTTP 500
Locale-JSON-Dateien mit 4042Lesbarkeits-Analyzer, ein Blogartikel404er im Hintergrund

Die Media-Kit-Seite ist der klarste Fall. Fünf Besucher landeten dort und sahen "brandFacts.mediaKit.title" und "brandFacts.mediaKit.description", wo Überschrift und Text stehen sollten. Keiner von ihnen klickte irgendwo. Die Seite lieferte 200 ohne Konsolenfehler, also hat nichts angeschlagen.

Was fünf Besucher auf /en/media-kit sahen
adaptlypost.com/en/media-kit
brandFacts.mediaKit.eyebrow brandFacts.mediaKit.title brandFacts.mediaKit.description brandFacts.mediaKit.assetsDescription
Jeder String auf der Seite ist der Schlüssel, den die Übersetzungsdatei hätte auflösen sollen. Die Seite lieferte 200.

Der Wechsel auf Portugiesisch produzierte eine 500-Seite mit "Ocorreu um erro inesperado". Der Retry-Button lud die portugiesische Startseite, und 17 Minuten später war derselbe 500er wieder da. Ein anderer Besucher bekam auf der englischen Startseite ein 500-Overlay, dessen Retry-Button "Intentar otra vez" hieß, Spanisch auf einer englischen Seite.

Der Sprachumschalter fordert außerdem Locale-Dateien an, die nicht existieren. Eine Session im Lesbarkeits-Analyzer protokollierte 24 404er im Hintergrund für Dateien wie /locales/fr/gdpr.json. Einen Blogartikel auf Spanisch umzuschalten tat dasselbe.

Nach Ende des Zeitfensters, am 18. August, ging die spanische Version des Safe-Zone-Guides mit dem Platzhalter "Original text" als Hauptüberschrift live.

Nichts davon wirft einen Fehler, der helfen würde. Die rohen Schlüssel und der Platzhalter sind eine Seite, die den falschen String rendert. Die Locale-404er sind Hintergrund-Requests, die niemand beobachtet. Nur die 500-Seiten würden jemanden alarmieren, und eine davon verschwand nach dem Retry von selbst.

Befund 4: die Glossar-URLs, die 404 liefern

Der größte Befund nach Session-Zahl und der langweiligste, und genau so hat er so lange überlebt.

Die Glossarartikel von AdaptlyPost liegen unter /blog/<slug>. Irgendwann wurden sie unter /blog/glossary-<slug> veröffentlicht und dann indexiert. Die Website hat für die Variante mit Präfix keine Route.

  • 382 verschiedene /blog/glossary-*-URLs tauchten in Fehlern auf, über 1.287 Sessions
  • Der größte Teil dieses Traffics kam direkt aus einem Suchergebnis
  • Zehn stichprobenartig geprüfte Slugs, abgeglichen mit dem Content-Verzeichnis: acht der zehn Artikel existieren, unter der URL ohne Präfix

Die Artikel existieren und ranken. Die URL, die Google indexiert hat, zeigt ins Leere, und eine einzige Redirect-Regel würde das beheben.

Die Glossar-404s in Zahlen
382verschiedene /blog/glossary-*-URLs mit 404
1.287Sessions, die auf einer landeten
8 von 10geprüfte Artikel existieren unter der URL ohne Präfix
1Redirect-Regel als Fix
Die meisten dieser Sessions kamen direkt aus einem Suchergebnis.

Was das Error-Monitoring sah

Von den 75.167 analysierten Aufzeichnungen trugen 11.598 einen Konsolen- oder Netzwerkfehler. 319 davon waren ein echtes, für den Besucher sichtbares Versagen. Das sind 2,8 % Präzision. Öffnen Sie Replays gefiltert nach "hat Fehler", und 97 von 100 sind ein blockierter Tracker oder ein abgebrochener Fetch.

In der anderen Richtung ist es schlimmer. Von den 3.338 echten Fehlern trugen 3.019 überhaupt keinen Fehler. Das meiste von dem, was oben steht, lebt in diesen 90 %: der tote PayPal-Button, die Billing-Regel, die geschluckten Klicks, die Media-Kit-Seite, die ihre Übersetzungsschlüssel ausgibt.

Das Fehlerflag als Detektor
Markierte Sessions, die echte Fehler waren2,8 %
Echte Fehler, die das Flag verpasste90 %
11.598 markiert, 319 echt. 3.338 echt, 3.019 unmarkiert. In beiden Richtungen falsch.

Vom Replay zur prüfbaren Änderung

Am Tag nach dem Ende des Zeitfensters nahm sich der Agent von Flowsery das Engagement-Selector-Problem aus Befund 2 vor, las die Aufzeichnung und öffnete einen Pull Request gegen die Codebasis von AdaptlyPost.

Seine Diagnose: Ein Tap auf eine Option änderte einen Zustand, den der Besucher nicht sehen konnte, also veränderte sich auf dem Bildschirm nichts, und der Recorder fing zehn unbeantwortete Klicks ein. Die Änderung baut das Control so um, dass es sich wie die Selectoren auf der Website verhält, die bereits funktionieren. Ein Commit, eine Datei.

Vom Rage Click zum Pull Request
Session aufgezeichnet
Problem dedupliziert
Agent liest das Replay
Änderung zur Prüfung geöffnet
Niemand hat darum gebeten und niemand hat das Replay geöffnet.

Wo die Dinge stehen

BefundSessions im ZeitfensterFehlersignalStatus
Checkout blockierte Zahlungen, fünf Arten72 von 5 MusternBehoben
Roher 400er bei der Anmeldung1HTTP 400Behoben
Selector schluckte Klicks48, auf 17 RoutenKeinesBehoben
Übersetzungen, die nicht geladen wurden9, auf 4 Routen3 von 9Behoben
Glossar-URLs liefern 4041.287HTTP 404Behoben

Was sich in dem Monat geändert hat, ist die Form des Backlogs. Vor dem 13. Juli war er das, was zufällig jemandem auffiel. Danach ist er eine sortierte Liste, in der jeder Eintrag eine Session-Zahl, ein Erstsichtungsdatum, einen Schweregrad, Reproduktionsschritte und eine Aufzeichnung zum Öffnen trägt.

"Wir sollten uns den Checkout ansehen" verliert gegen ein Roadmap-Item. "Sieben Leute wollten zahlen und der Checkout hat sie gestoppt, auf fünf verschiedene Arten, und hier ist die Aufzeichnung von einem davon" verliert nicht.

Was sich übertragen lässt

Derselbe Monat, zwei Sichten
Was der Stack sah
  • Einen 200er mit einer vollständig gerenderten Seite
  • Einen 200er, der einen Fehlertext trägt
  • Einen Click-Handler, der normal feuerte
  • 11.598 markierte Sessions, 319 davon echt
Was die Aufzeichnungen sahen
  • Eine Überschrift, die brandFacts.mediaKit.title lautet
  • Einen zahlenden Kunden, dem ein Upgrade verweigert wurde
  • Zehn unbeantwortete Klicks, dann geht der Besucher
  • 3.338 echte Fehler, 66 verschiedene Ursachen
Neunzig Prozent der rechten Spalte sind für die linke unsichtbar.

Sortieren Sie nach Kosten, nicht nach Menge. Die Glossar-404er trafen 1.287 Sessions und die Checkout-Bugs sieben, und die Checkout-Bugs sind mehr wert.

Behandeln Sie stumme Controls als Bugs ohne Telemetrie. Ein totes Dropdown wirft nichts, loggt nichts und liefert 200. Der einzige Beleg, dass es existiert, ist ein Mensch, der zehnmal auf dieselbe Stelle klickt, und dieser Beleg liegt in der Aufzeichnung oder nirgends.

Lesen Sie, was die Seite zeigt, nicht, was der Server zurückgegeben hat. Eine Überschrift, die brandFacts.mediaKit.title lautet, ist ein 200er ohne Konsolenfehler, und eine spanische Seite mit der Hauptüberschrift "Original text" ebenso. Keines von beiden erscheint als Funnel-Abbruch, weil der Besucher den Funnel nie betreten hat.

Sehen Sie, was Ihr Error-Dashboard übersieht

Dieselbe Analyse, die bei AdaptlyPost lief, auf Ihrer eigenen Website.