Bekannte Probleme
Erfasste Probleme und deren Behebung
Erster API request nach Inaktivität dauert 2-3s länger
Dein erster API request nach einer Phase der Inaktivität dauert ~2-3s länger, während der proxy pool aufwärmt. Danach antworten requests normal.
Wir haben dies im September 2026 erneut gemessen: Der erste Request nach einer Ruhephase ist jetzt genauso schnell wie die nachfolgenden Requests.
Dashboard-Nutzungsdiagramme zeigen keine Zeitzonen-Labels
Nutzungsdiagramme in deinem Dashboard zeigen Zeitstempel in UTC, aber geben die Zeitzone nicht an. Wenn du dich außerhalb von UTC befindest, sehen die Zeiten ohne Kontext falsch aus.
Dashboard-Diagramme und -Tabellen zeigen jetzt alle Zeitangaben in deiner Zeitzone an, übernommen aus deinem Browser.
Analytics zeigte eine kurze Datenlücke während der Migration
Während der Datenbankmigration fielen die Echtzeit-Analytics für einige Stunden aus. Es gingen keine Daten verloren. Die Lücke betraf nur die Live-Sichtbarkeit, nicht die historischen Daten.
Wir haben alle historischen Daten (über 260 Millionen Datensätze) nachgetragen und die Konsistenz pro Tag überprüft. Die Echtzeit-Ingestion war innerhalb von Stunden wieder verfügbar.
Safari-Nutzer erlebten einen Login-Redirect-Loop im Dashboard
Wenn du Safari genutzt hast, löste der Login ins Dashboard einen Redirect-Loop aus. Eine Besonderheit der Cookie-Verarbeitung in WebKit führte dazu, dass die Session über Subdomains hinweg fehlschlug.
Wir haben die Cookie-Attribute für eine Subdomain-übergreifende Kompatibilität korrigiert. Der Login funktioniert jetzt in allen gängigen Browsern fehlerfrei.
Veraltete Proxies blieben zu Spitzenzeiten im Pool
Während der Spitzenlast kam die Proxy-Validierungs-Pipeline nicht hinterher. Einige Requests trafen auf kürzlich fehlgeschlagene Proxies, bevor der Pool sie entfernte.
Wir haben parallele Health-Checks und eine schnellere Entfernung toter Proxies hinzugefügt. Der Pool bleibt nun auch bei 10-facher Normallast aktuell.
Timeouts bei Browser-Requests unter hoher JS-Last
Requests im Browser-Modus brachen auf Seiten mit großen JavaScript-Bundles mit Timeouts ab. Headless Chrome hatte nicht genügend Shared Memory, um gleichzeitige Sessions zu verarbeiten.
Wir haben den Shared Memory für Browser-Sessions erhöht und Ressourcenlimits pro Request hinzugefügt. Die Timeout-Rate sank von ~8% auf unter 0,5%.