Historique des pannes de Signalfx Us1

1. 27 octobre 2026 à 22:21 UTCinvestigating

   nous avons trouvé l'ApI défaillant avec 500, donc la page de profilage de code serait inaccessible ou les erreurs seraient vus dans l'interface utilisateur

2. 27 octobre 2026 à 22:23 UTCidentified

   La question a été identifiée et mise en œuvre

3. 27 octobre 2026 à 22:24 UTCmonitoring

   Un correctif a été mis en place et nous suivons les résultats.

4. 28 octobre 2026 à 01:38 UTCresolved

   Cet incident a été résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 23 octobre 2026 à 07:33 UTCinvestigating

   Nous enquêtons sur un problème avec l'intégration AWS CloudWatch. Certains clients peuvent voir des étiquettes de ressources manquantes ou dépassées sur les paramètres AWS, et les changements de configuration de flux métrique peuvent ne pas être appliqués. L'ingestion métrique n'est pas affectée. Nous fournirons une mise à jour dès que de plus amples renseignements seront disponibles.

2. 23 octobre 2026 à 09:15 UTCidentified

   Nous avons constaté que l'intégration d'AWS CloudWatch dégradée est causée par une perturbation continue d'AWS dans la région me-central-1 (EAU), y compris AWS CloudWatch et l'API de marquage des groupes de ressources. Les clients ayant des ressources AWS dans cette région peuvent voir des étiquettes de ressources manquantes ou périmées sur les métriques AWS, et les changements de configuration de flux métrique peuvent ne pas être appliqués. L'ingestion métrique n'est pas affectée. AWS n'a pas fourni de calendrier de rétablissement et recommande de migrer vers une autre région.

3. 23 octobre 2026 à 21:12 UTCresolved

   Spunk a confirmé que l'intégration dégradée d'AWS CloudWatch dans la région me-central-1 (EAU) est causée par une perturbation régionale d'AWS continue en dehors du contrôle de Splunk. Le SSFE n'a pas fourni de calendrier de rétablissement et recommande de migrer les ressources affectées vers une autre région. L'ingestion métrique n'est pas affectée. Nous identifions les clients touchés et nous contacterons individuellement pour discuter des prochaines étapes. Si vous avez des préoccupations immédiates, veuillez contacter votre équipe de compte.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 22 octobre 2026 à 21:56 UTCinvestigating

   Une dégradation de la performance du pipeline d'ingestion de données Spunk APM retarde le traitement et le stockage des données de traces brutes de plus de cinq minutes. Aucune donnée n'est perdue pour l'instant et MetricSets n'est pas touchée, mais les données les plus récentes peuvent ne pas être disponibles dans les résultats de recherche en trace.

2. 22 octobre 2026 à 21:58 UTCidentified

   Nous continuons de travailler sur une solution à ce problème.

3. 22 octobre 2026 à 22:01 UTCmonitoring

   Un correctif a été mis en place et nous suivons les résultats.

4. 22 octobre 2026 à 22:10 UTCresolved

   Cet incident a été résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 15 octobre 2026 à 18:57 UTCinvestigating

   Nous enquêtons sur une dégradation de l'application web Splunk Observability Cloud pour certains clients. L'ingestion de données n'est pas affectée actuellement. Nous fournirons une mise à jour dès que possible.

2. 15 octobre 2026 à 21:04 UTCinvestigating

   Nos équipes d'ingénierie s'emploient activement à résoudre les problèmes de performance identifiés dans l'interface utilisateur Web d'observation Splunk, nous partagerons une nouvelle mise à jour dès que possible.

3. 15 octobre 2026 à 21:11 UTCmonitoring

   Un correctif a été mis en place et nous suivons les résultats.

4. 15 octobre 2026 à 21:20 UTCresolved

   Cet incident a été résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 11 octobre 2026 à 04:09 UTCinvestigating

   Les graphiques d'un sous-ensemble de clients peuvent ne pas être chargés. L'ingestion de données n'est pas affectée. Nous enquêtons et nous fournirons une mise à jour sous peu.

2. 11 octobre 2026 à 04:24 UTCmonitoring

   Les cartes et les tableaux de bord sont en bonne santé et nous surveillons le rétablissement.

3. 11 octobre 2026 à 05:34 UTCresolved

   Cet incident a été résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 3 octobre 2026 à 03:02 UTCinvestigating

   Nous enquêtons sur les retards dans le traitement des résultats des tests de surveillance synthétique de Splunk. Les tests de surveillance synthétique sont opérationnels, mais les mesures peuvent manquer jusqu'à ce que le problème soit résolu.

2. 3 octobre 2026 à 03:03 UTCinvestigating

   Nous continuons d'enquêter sur cette question.

3. 3 octobre 2026 à 03:03 UTCidentified

   Le problème a été identifié et une solution est en cours de mise en oeuvre.

4. 3 octobre 2026 à 03:13 UTCmonitoring

   Un correctif a été mis en place et nous suivons les résultats.

5. 3 octobre 2026 à 03:18 UTCresolved

   Cet incident a été résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 29 septembre 2026 à 15:02 UTCinvestigating

   Certains clients peuvent subir des retards dans certaines cartes et certains détecteurs. L'ingestion de données n'est pas affectée. Nous enquêtons et nous fournirons une mise à jour sous peu.

2. 29 septembre 2026 à 15:54 UTCinvestigating

   Nous continuons d'enquêter sur les retards constatés dans certains cartes et détecteurs. Nos équipes d'ingénierie poursuivent le dépannage et partageront une mise à jour sous peu.

3. 29 septembre 2026 à 16:10 UTCmonitoring

   Un correctif a été mis en place et nous suivons les résultats.

4. 29 septembre 2026 à 17:26 UTCmonitoring

   Le rétablissement des services a été confirmé. Nous continuerons de surveiller de près la performance du système et de partager les mises à jour en conséquence.

5. 29 septembre 2026 à 18:07 UTCresolved

   Notre équipe d'ingénierie a confirmé que la réparation déployée a stabilisé les services touchés dans toute la région US1. Cet incident est maintenant considéré comme résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 27 septembre 2026 à 02:17 UTCresolved

   De 17h45 à 18h20 PT, la dégradation de la performance du pipeline de traitement des traces de Spunk APM a retardé de plus de cinq minutes le dépannage de MetricSets. Par conséquent, l'expérience de dépannage APM, les cartes de service et Tag Spotlight n'ont pas accès aux données les plus récentes. Le traitement des données pour les flux de travail des entreprises, qui dépend également de ce pipeline, est également retardé. L'ingestion de données traces n'est pas affectée à l'heure actuelle; les ensembles de surveillance de niveau de service et de niveau d'extrémité et les détecteurs construits à partir d'eux ne sont pas non plus touchés.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 18 septembre 2026 à 15:40 UTCresolved

   Certains clients voient des défaillances de connexion en raison d'erreurs de certificat. Les clients déjà enregistrés ne sont pas touchés. La question a été réglée.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 15 septembre 2026 à 14:41 UTCidentified

   À partir de 5h50 HAP, l'ingestion de points de données au niveau des archives a été touchée, ce qui a entraîné l'acceptation d'un petit nombre de points de données. L'impact était limité au niveau des archives. Les détecteurs et les cartes n'ont pas été touchés. Nous avons mis en place des mesures correctives et nous surveillons activement le système afin d'assurer une stabilité continue. Nous fournirons des mises à jour toutes les 15 minutes.

2. 15 septembre 2026 à 14:52 UTCidentified

   A partir de 7h48, nous n'observons plus de données abandonnées. Le système continue de se remettre, et nous le surveillons activement pour assurer une stabilité continue.

3. 15 septembre 2026 à 14:54 UTCmonitoring

   Le système continue de se remettre, et nous le surveillons activement pour assurer une stabilité continue.

4. 15 septembre 2026 à 15:33 UTCmonitoring

   Le système montre des progrès constants dans sa récupération. Nos équipes restent actives et observent étroitement les paramètres du système pour assurer une stabilité continue

5. 15 septembre 2026 à 16:50 UTCmonitoring

   Nous avons rétabli avec succès l'ingestion de données et constatons des progrès constants au fur et à mesure que l'arriéré de données est traité. Nous surveillons activement ce processus afin d'assurer le retour de la fonctionnalité complète du service le plus rapidement possible.

6. 15 septembre 2026 à 17:59 UTCmonitoring

   Nous continuons de surveiller pour assurer la fonctionnalité complète du service.

7. 15 septembre 2026 à 18:58 UTCmonitoring

   Nous continuons de surveiller le système pour assurer une stabilité continue. Nos équipes continuent d'observer activement les paramètres de performance pour confirmer que toutes les opérations fonctionnent comme prévu.

8. 15 septembre 2026 à 20:17 UTCmonitoring

   Pour accélérer le processus de rétablissement, nous ajoutons actuellement des capacités supplémentaires à nos grappes. Nos équipes restent actives et continuent de surveiller les performances du système à mesure qu'il se stabilise.

9. 15 septembre 2026 à 21:28 UTCresolved

   Le système a récupéré et nous ingérons des données archivées sans délai.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 12 septembre 2026 à 16:32 UTCinvestigating

   L'ingestion de datapoint est affectée et nous laissons tomber des datapoints de 8:52 PDT. Nous enquêtons et fournirons une mise à jour toutes les 15 minutes.

2. 12 septembre 2026 à 16:55 UTCmonitoring

   Entre 8h52 PDT et 9h47 PDT, un petit nombre de points de données pour les nouvelles séries chronologiques n'ont pas été acceptés. Par conséquent, il se peut que de nouvelles séries chronologiques aient connu un retard avant de devenir disponibles dans les cartes et les détecteurs. Des mesures correctives sont en place et nous continuons de surveiller le système pour assurer la stabilité.

3. 12 septembre 2026 à 17:37 UTCresolved

   Le problème a été résolu, et l'ingestion de données fonctionne normalement. Nous avons confirmé que le système demeure stable après l'assainissement. Cet incident est maintenant résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 9 septembre 2026 à 00:12 UTCinvestigating

   Une dégradation des données de traces ingère le chemin de Spunk APM provoque la chute et la perte de traces. Nous enquêtons sur la question et fournirons une mise à jour dès que possible.

2. 9 septembre 2026 à 00:41 UTCresolved

   Cet incident a été résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 28 août 2026 à 18:01 UTCinvestigating

   Nous enquêtons sur une panne majeure de l'assistant d'observation de Spunk.

2. 28 août 2026 à 18:20 UTCidentified

   Le problème a été identifié comme une panne Azure OpenAI et nous procédons à une solution de rechange.

3. 28 août 2026 à 18:25 UTCmonitoring

   Un correctif a été mis en place et nous suivons les résultats.

4. 28 août 2026 à 19:26 UTCresolved

   Phase de surveillance terminée. La question a été réglée.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 25 août 2026 à 18:44 UTCinvestigating

   À partir de 08/25/2026, 11:38AM PDT, une dégradation de la performance du pipeline de traitement des traces de Spunk APM provoque un retard de plus de cinq minutes dans le dépannage de MetricSets. Par conséquent, l'expérience de dépannage APM, les cartes de service et Tag Spotlight n'ont pas accès aux données les plus récentes. Le traitement des données pour les flux de travail des entreprises, qui dépend également de ce pipeline, est également retardé. L'ingestion de données traces n'est pas affectée à l'heure actuelle; les ensembles de surveillance de niveau de service et de niveau d'extrémité et les détecteurs construits à partir d'eux ne sont pas non plus touchés.

2. 25 août 2026 à 19:21 UTCinvestigating

   Nous continuons d'enquêter sur cette question.

3. 25 août 2026 à 19:44 UTCidentified

   Le problème a été identifié et une solution est en cours de mise en oeuvre.

4. 25 août 2026 à 20:02 UTCmonitoring

   Un correctif a été mis en place et nous suivons les résultats.

5. 25 août 2026 à 20:25 UTCmonitoring

   Nos équipes continuent de surveiller la situation afin d'assurer l'assainissement complet.

6. 25 août 2026 à 21:07 UTCresolved

   Cet incident a été résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 1 août 2026 à 14:35 UTCinvestigating

   Problèmes liés au traitement des alertes qui entraînent des notifications tardives. Nous enquêtons actuellement sur la question.

2. 1 août 2026 à 15:33 UTCinvestigating

   Nous enquêtons actuellement sur des latences de notification élevées. Les clients peuvent avoir des retards dans la réception des notifications d'alerte. Nous travaillons activement à résoudre ce problème et fournirons des mises à jour à mesure que nous progresserons. Nous apprécions votre patience.

3. 1 août 2026 à 15:55 UTCidentified

   Nous avons identifié et sommes en train de résoudre activement le problème qui cause des alertes différées. La correction a été mise en œuvre et montre déjà une amélioration significative des délais de notification. Bien que certaines notifications qui étaient en attente avant notre correction puissent encore connaître des retards mineurs à mesure que le système se rattrape, de nouvelles notifications sont livrées normalement. Nous apprécions votre patience et continuerons de suivre la situation de près.

4. 1 août 2026 à 17:09 UTCidentified

   Nous travaillons activement à résoudre ce problème. Les clients peuvent continuer à connaître des retards dans la livraison des avis. Cela inclut les notifications nouvellement générées, qui sont traitées derrière les événements antérieurs dans la file d'attente. L'équipe étudie activement la cause fondamentale et s'emploie à éliminer l'arriéré de notifications en attente. Comme mesure d'atténuation temporaire, nous avons désactivé les prévisualisations d'image dans les notifications pour améliorer la vitesse de traitement. Les notifications ne seront que texte pour le moment. Nous apprécions votre patience et fournirons d'autres mises à jour au fur et à mesure des progrès réalisés.

5. 1 août 2026 à 17:31 UTCmonitoring

   Nous avons mis en place un correctif pour corriger les retards de notification. Notre surveillance montre une amélioration significative des délais d'envoi des notifications, et nous suivons de près le rendement pour nous assurer que la question est entièrement résolue. Merci de votre patience alors que nous travaillons à rétablir le service complet.

6. 1 août 2026 à 18:21 UTCresolved

   Les retards de livraison des notifications ont été entièrement résolus. Toutes les notifications en attente ont été traitées et le système fonctionne maintenant normalement.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 31 juillet 2026 à 02:51 UTCinvestigating

   Une dégradation de la performance du pipeline de traitement des MPA Spunk entraîne un retard de plus de cinq minutes dans la surveillance des MetricSets. L'ingestion de données n'est pas touchée, mais les tableaux de bord des services, des paramètres et des flux de travail, et d'autres cartes et détecteurs construits à partir de Monitoring MetricSets sont touchés.

2. 31 juillet 2026 à 02:54 UTCinvestigating

   Nous poursuivons nos recherches sur le problème.

3. 31 juillet 2026 à 03:44 UTCinvestigating

   Nous continuons d'enquêter sur cette question.

4. 31 juillet 2026 à 04:07 UTCidentified

   Le problème a été identifié et une solution est en cours de mise en oeuvre.

5. 31 juillet 2026 à 04:08 UTCmonitoring

   Un correctif a été mis en place et nous suivons les résultats.

6. 31 juillet 2026 à 04:33 UTCresolved

   Cet incident a été résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 24 juillet 2026 à 21:54 UTCresolved

   L'ingestion de données pour les séries chronologiques métriques nouvelles ou réactivées a été affectée entre 2:28 PM PST et 2:47 PM PST. Il y a eu une perte partielle de données pour les nouvelles séries chronologiques métriques au cours de cette période. Cette situation est maintenant rétablie.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 22 juillet 2026 à 18:02 UTCresolved

   L'ingestion de données pour les nouvelles séries chronologiques métriques a été affectée entre 10:37 AM PST et 10:39 AM PST. Il y a eu une perte partielle de données pour les nouvelles séries chronologiques métriques au cours de cette période. Cette situation est maintenant rétablie.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 14 juillet 2026 à 11:25 UTCinvestigating

   À partir de 4a PT, nous enquêtons sur une panne majeure de l'application web Splunk Observability Cloud. L'ingestion de données n'est pas affectée actuellement. Nous fournirons une mise à jour dès que possible.

2. 14 juillet 2026 à 12:13 UTCinvestigating

   Nous poursuivons nos recherches sur le problème.

3. 14 juillet 2026 à 12:28 UTCmonitoring

   Un correctif a été mis en place et nous suivons les résultats.

4. 14 juillet 2026 à 12:38 UTCresolved

   Cet incident a été résolu. Veuillez noter que l'API Cloud d'observation de Splunk a également été affectée pendant cet incident.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 8 juillet 2026 à 10:52 UTCresolved

   Entre 1a PDT et 2:50a PDT, toute intégration GCP qui avait le réglage "Sync all (dynamiquement) listed projects" activé a eu une partie des données Cloud Monitoring de GCP abandonné. Cette question a été résolue. Les clients peuvent voir des lacunes dans les cartes et les détecteurs qui utilisent les mesures de surveillance de GCP Cloud affectées. Les paramètres AWS CloudWatch et Azure Monitor ne sont pas touchés.

Traduit automatiquement depuis la mise à jour officielle de l'incident.