Ce que cette page vérifie
L’API, la base et Redis, lus sur le point de santé au chargement et à chaque actualisation. Les sources tierces, les imports de flux et vos intégrations ne sont pas couverts.
État des systèmes
Vérification de l’état des services…
Dernière mise à jour : —
Vérifications
État des services
streamingVérification de l’état des services…
API
Base de données
Cache de renseignement
Historique
Incidents récents
Des pages TAXII vides ont bloqué des clients de flux
résoluUne page TAXII s’arrêtait après avoir examiné 8 000 clés. Avec des filtres sélectifs comme added_after ou min_score, elle pouvait revenir sans objet, avec un lien next, et un client qui ne suit next que lorsqu’une page contient des objets redemandait la même page. Pendant une dizaine de jours avant le correctif, les interrogations de malicious-file-hashes par ces clients n’ont presque rien livré ; celles de malicious-urls se sont bloquées plusieurs heures le 2026-09-15, puis le 2026-09-19. Corrigé le 2026-09-23 : une page encore vide continue d’examiner les clés, jusqu’à 64 000 dans la limite de 12 secondes.
Nouvelle perte du cache des données de menace
résoluLe cache qui contient le corpus d’indicateurs a été recréé à 09:30 UTC et a de nouveau perdu ses données : 49,0 millions de clés avant, 29,1 millions après, soit environ 41 % du corpus manquant. Le rechargement qui le reconstitue a été interrompu par un déploiement l’après-midi même : les recherches, les flux TAXII et les blocklists ont tourné sur le corpus réduit jusqu’à la fin d’un rechargement ultérieur. Les données de rançongiciels ont manqué au tableau des menaces pendant environ une journée.
Perte du cache des données de menace pendant une maintenance
résoluLe cache qui contient le corpus d’indicateurs a été recréé pendant une maintenance du serveur et a perdu ses données. Les recherches, les flux TAXII et les blocklists ont tourné sur un corpus réduit jusqu’à ce que les rechargements le reconstituent depuis les sources. Les collections TAXII signalées par les organisations et les téléchargements de leurs blocklists lisaient une copie conservée dans ce cache, que rien n’a reconstituée : ils n’ont renvoyé que les indicateurs approuvés ensuite jusqu’au 2026-09-25, date à laquelle ils sont passés sur la base de données. Les comptes, les clés d’API et la facturation, conservés dans la base, n’ont pas été touchés.
Saturation des connexions à la base
résoluPendant 48 heures, une part croissante des consultations de rapport n’atteignait plus la base, la demande de connexions dépassant le pool. Corrigé en faisant passer le trafic par un pooler en mode transaction.
Périmètre
Comment lire cette page
99,9 %
Objectif de disponibilité
La disponibilité mensuelle de l’API est un objectif interne, pas un taux mesuré ni un SLA contractuel.
Journal des incidents
Les entrées sont ajoutées à la main et peuvent apparaître après le début d’un incident. Les intégrations doivent interroger le point de santé et gérer les requêtes en échec.
Recevoir les nouveautés
L’actualité du produit et de la plateforme par e-mail. Les incidents sont publiés sur cette page.
Articles liés
Pour en savoir plus sur notre infrastructure et les bonnes pratiques.
- Intégrer l’API de renseignement sur les menaces
Bonnes pratiques pour construire des intégrations de sécurité tolérantes aux pannes.
- Construire un SOC moderne avec du renseignement
Comment gérer proprement les limites de débit dans votre intégration.
- Menaces cloud et protection multi-cloud
Évaluer les dépendances cloud et les exigences d’une intégration.