Anomalies connues
Suivi des problèmes identifiés et de leur résolution
La première request API après inactivité prend 2-3s de plus
Votre première request API après une période d'inactivité prend ~2-3s de plus pendant que le pool de proxy préchauffe. Les requests suivantes répondent normalement.
Nous avons mesuré cela à nouveau en septembre 2026 : la première requête après une période d'inactivité est désormais aussi rapide que les requêtes qui la suivent.
Les graphiques d'utilisation du tableau de bord n'affichent pas les étiquettes de fuseau horaire
Les graphiques d'utilisation de votre tableau de bord affichent les horodatages en UTC mais n'indiquent pas le fuseau horaire. Si vous êtes en dehors du fuseau UTC, les heures semblent incorrectes sans contexte.
Les graphiques et tableaux du tableau de bord affichent désormais toutes les heures dans votre propre fuseau horaire, récupéré depuis votre navigateur.
Les analyses ont montré une brève interruption des données pendant la migration
Pendant la migration de la base de données, les analyses en temps réel ont été interrompues pendant quelques heures. Aucune donnée n'a été perdue. L'interruption n'a affecté que la visibilité en direct, et non les enregistrements historiques.
Nous avons réinjecté toutes les données historiques (plus de 260M d'enregistrements) et vérifié la cohérence par jour. L'ingestion en temps réel a été rétablie en quelques heures.
Les utilisateurs de Safari ont rencontré une boucle de redirection de connexion sur le tableau de bord
Si vous avez utilisé Safari, la connexion au tableau de bord a déclenché une boucle de redirection. Une particularité de la gestion des cookies par WebKit a provoqué l'échec de la session entre les sous-domaines.
Nous avons corrigé les attributs de cookie pour assurer la compatibilité entre les sous-domaines. La connexion fonctionne désormais correctement sur tous les principaux navigateurs.
Des proxys obsolètes sont restés dans le pool pendant les heures de pointe
Pendant les pics d'utilisation, le pipeline de validation des proxys n'a pas pu suivre la cadence. Certaines requêtes ont atteint des proxys en échec récent avant que le pool ne les évince.
Nous avons ajouté des contrôles d'état parallèles et une éviction plus rapide des proxys morts. Le pool reste désormais à jour même sous une charge 10 fois supérieure à la normale.
Délai d'attente dépassé pour les requêtes de navigateur sous de fortes charges JS
Les requêtes en mode navigateur expiraient sur les pages contenant de lourds bundles JavaScript. Headless Chrome ne disposait pas de suffisamment de mémoire partagée pour traiter les sessions simultanées.
Nous avons augmenté la mémoire partagée pour les sessions de navigateur et ajouté des limites de ressources par requête. Le taux d'expiration est passé de ~8% à moins de 0.5%.