Historique des pannes de Honeycombio

1. 22 octobre 2026 à 16:06 UTCidentified

   Nous avons identifié un problème où les courriels pour SLO, Triggers et Anomalie Detection ne sont pas envoyés. Nous travaillons pour réparer.

2. 22 octobre 2026 à 17:07 UTCresolved

   Entre 03:53 PM UTC à 4:08 PM UTC, nous avons vu des échecs d'envoi de courriel augmenter dans lequel un petit nombre de clients (10 entreprise, 8 libre-service, et 1 pro plan) ont été touchés. Cela est venu à 508 emails au total, soit ~1% de notre email quotidien. Nous veillons à ce que ce mode d'échec ne puisse pas se reproduire.

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

1. 20 octobre 2026 à 14:04 UTCinvestigating

   Nous étudions actuellement la dégradation de divers services dans notre région américaine.

2. 20 octobre 2026 à 15:18 UTCinvestigating

   Nous avons identifié et isolé le service touché et voyons la récupération dans l'exécution des requêtes. Le traitement des SLO reste dégradé.

3. 20 octobre 2026 à 16:26 UTCresolved

   Le traitement SLO a complètement récupéré. Tous les services sont maintenant fonctionnels.

4. 21 octobre 2026 à 23:26 UTCpostmortem

   Le 20 octobre, nous avons connu environ trois heures de service dégradé dans la région américaine. * De 13:30 à 14:40 UTC, requête, l'interface utilisateur Honeycomb, l'API de gestion et les déclencheurs ont connu des taux de latence et d'erreur élevés, avec l'impact le plus élevé entre 13:55 et 14:10 UTC. Pendant ce temps, les clients peuvent avoir eu des requêtes lentes ou ratées et une interface utilisateur lente, et certaines alertes de déclenchement peuvent avoir été tardives ou manquées. * De 13h26 à environ 16h10 UTC, le traitement de l'ALS a été retardé, de sorte que les données de l'ALS peuvent être apparues hors de date et les alertes de gravure peuvent avoir été retardées ou manquées pendant cette période. * De 13:57 à 14:09 UTC, environ la moitié des demandes à l'événement ingèrent API a reçu 5xx erreurs, avec un impact moindre entre 13:48 et 13:55 UTC \(1% taux d'erreur\) et pendant environ une minute à 14:15 UTC \(1,9% taux d'erreur\). La télémétrie rejetée pendant ces périodes n'a pas été ingérée à moins que l'expéditeur ne l'ait réévalué avec succès. Les clients peuvent voir des lacunes dans leurs données pour ces périodes, y compris dans les déclencheurs et les ALS qui les couvrent. Nos ingénieurs à l'appel ont été mis en première page à 13h43 UTC par une alerte au sujet des déclencheurs ne fonctionnant pas à l'heure, et nous avons lancé notre réponse interne incident comme d'autres alertes suivies. Notre enquête a révélé que le CPU de la base de données primaire était saturé par un grand nombre de requêtes de lecture à long terme. Nous avons effectué une panne de base de données pour soulager la charge. Cela a brièvement allégé la pression, mais les mêmes questions ont rapidement réapparu sur le nouveau primaire, donc il n'a pas résolu le problème. Nous avons ensuite réduit la charge de base de données en mettant fin à ces requêtes et en arrêtant temporairement le traitement SLO, qui a rétabli les autres services touchés. Une fois qu'un timeout côté base de données a été mis en place sur la requête responsable, nous avons repris le traitement SLO, qui a ensuite rattrapé, et nous avons réparé les données historiques SLO. Ces requêtes proviennent d'une vérification que notre traitement SLO fonctionne chaque fois que les paramètres d'un environnement Honeycomb changent. Dans une grande majorité de cas, il se termine en quelques millisecondes. Pour le 0,1% de nos environnements avec un nombre exceptionnellement élevé d'ALS et de champs calculés, cependant, la base de données l'a exécuté de manière très inefficace, et une mise à jour de routine à un tel environnement a rendu la vérification trop lente pour être terminée. Ces requêtes se sont poursuivies après l'expiration du délai de service demandé, et des tentatives répétées ont augmenté la charge sur une base de données partagée par plusieurs services. Pour éviter que cela ne se reproduise, en plus du timeout côté base de données, nous avons changé la façon dont la base de données exécute la requête pour des environnements comme celui-ci, qui a ramené son temps d'exécution de minutes à quelques millisecondes. Nous avons également ajusté nos seuils d'alerte pour faire en sorte qu'un ingénieur sur appel soit informé rapidement des changements futurs de charge de la base de données.

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

1. 20 octobre 2026 à 17:07 UTCresolved

   De 13:57 à 14:09 UTC, événement ingérant dans l'environnement de production américain Honeycomb a été dégradé par un incident concomitant. Au cours de cette fenêtre, environ 53% des événements entrants ont reçu 5xx erreurs.

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

1. 21 août 2026 à 15:21 UTCidentified

   Canvas ne se charge pas pour les clients des régions des États-Unis et de l'UE et nous avons identifié ce que nous croyons être la cause et sommes en train de déployer une solution.

2. 21 août 2026 à 15:25 UTCmonitoring

   Nous avons déployé le correctif et voyons la récupération de la fonctionnalité Canvas normale.

3. 21 août 2026 à 15:59 UTCresolved

   Cet incident a été résolu.

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

1. 10 août 2026 à 13:01 UTCmonitoring

   De 11:36UTC à 12:43UTC, les requêtes en US1 qui lisent des données plus anciennes ont renvoyé des erreurs ou chronométré. Les questions sur les données récentes n'étaient pas touchées, et aucune télémétrie n'est perdue. Le problème a été identifié et une correction est en place. Nous suivons actuellement la situation pour confirmer la résolution.

2. 10 août 2026 à 20:35 UTCresolved

   La solution est en place et nous avons confirmé la résolution. Les demandes et les ALS sont traitées normalement.

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

1. 31 juillet 2026 à 15:42 UTCresolved

   Entre 10h30 et 11h00 HAE, nous avons connu des erreurs de requête élevées et de la lenteur. L'impact s'est amenuisé, et nous enquêtons actuellement sur la situation et la suivons.

2. 21 août 2026 à 13:18 UTCpostmortem

   À partir de 9h50 Central Le 31 juillet, nous avons reçu des alertes concernant la santé et la latence. La cause a finalement été traquée à un choc de deux facteurs différents. Tout d'abord, nous avons introduit Lambda Managed Instances \(LMI\) dans notre architecture de requête, qui se comporte comme des lambdas classiques de bien des façons et avait été introduit dans le cadre de travaux sur l'amélioration des performances de requête dans le but d'une expérience utilisateur meilleure et plus rapide. Malheureusement, une différence entre les lambdas classiques et les LMIs que nous avons découverts est l'arrêt dur de 15 minutes de lambdas classiques n'existe pas sur les LMIs, ce qui signifie que certaines hypothèses intégrées dans notre système de requête ne tiennent plus. Au moment de l'incident, notre nouvelle fonction Canvas était de lancer des lots de requêtes pour un client qui devrait avoir un auto imposé une minute de temps. Ce délai n'a pas été correctement communiqué à la lambda, et alors qu'avec les lambdas classiques la tâche se couperait automatiquement à 15 minutes, les nouveaux IMT n'appliquaient pas ce type de mécanisme de sécurité. En conséquence, certaines grandes requêtes étaient en cours d'exécution pendant jusqu'à 30 minutes, entraînant des latences de requête à travers le système et entraînant des erreurs pour les utilisateurs essayant d'exécuter de nouvelles requêtes. Le système s'est rétabli par 10 h 10, 20 minutes plus tard, lorsque les grandes questions ont disparu, mais nous avons continué à enquêter sur la cause de l'incident. Une fois que nous avons identifié cette faiblesse dans notre architecture de requête, nous avons commencé à travailler pour la corriger et empêcher que le même incident ne se reproduise. Nous avons expédié tous les suivi des incidents associés.

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

1. 27 juillet 2026 à 13:13 UTCinvestigating

   Nous assistons à des échecs intermittents dans la région de l'UE. Nous enquêtons activement sur la cause.

2. 27 juillet 2026 à 13:52 UTCinvestigating

   Nous continuons de voir des problèmes avec les déclencheurs et nous remarquons également des problèmes avec l'interrogation. Nous enquêtons pour la cause des deux.

3. 27 juillet 2026 à 16:01 UTCmonitoring

   Nous avons identifié la source du problème, appliqué une correction temporaire et travaillons sur une correction permanente. Nous continuons de suivre la situation.

4. 27 juillet 2026 à 19:46 UTCmonitoring

   Nous voyons une régression dans les performances avec une dégradation partielle des déclencheurs et des requêtes. Nous travaillons à remédier à cette situation.

5. 27 juillet 2026 à 22:51 UTCmonitoring

   La dégradation partielle a été résolue pour tous les clients, à l'exception de ceux spécifiquement contactés. Nous travaillons sur des mesures d'atténuation afin de rétablir pleinement la fonctionnalité de déclenchement pour tous.

6. 28 juillet 2026 à 18:21 UTCmonitoring

   Nous restons à l'affût de tout autre problème.

7. 28 juillet 2026 à 18:30 UTCresolved

   La dégradation dans les requêtes et les déclencheurs a été résolue et nous revenons à la fonctionnalité complète.

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

1. 2 juillet 2026 à 18:10 UTCinvestigating

   We are currently investigating this issue.

2. 2 juillet 2026 à 18:13 UTCmonitoring

   Clearing the CDN cache appears to have solved the issue.

3. 3 juillet 2026 à 00:31 UTCresolved

   This incident has been resolved.

1. 29 juin 2026 à 22:07 UTCmonitoring

   Starting at 14:24 PT, there was an issue with the Activity Log causing events to stop being processed. You may notice a gap starting at that time. We are slowly backfilling these events and do not expect any data loss to occur. We expect the full data log to be restored around 17:30 PT.

2. 30 juin 2026 à 00:47 UTCresolved

   Backfill of the Activity Log events has completed. All events during the affected period should be present.

1. 25 juin 2026 à 18:10 UTCinvestigating

   We are investigating an issue with delayed ingest in the EU region. SLOs and Trigger evaluations may also be delayed.

2. 25 juin 2026 à 18:31 UTCmonitoring

   We are monitoring the situation. Events may have been delayed between 17:53 and 18:04 UTC.

3. 25 juin 2026 à 20:41 UTCresolved

   This incident has been resolved.

1. 24 juin 2026 à 18:14 UTCinvestigating

   We are investigating an issue with delayed ingest in the US and EU region. Our engineers are rolling back a recent deploy. SLOs and Trigger evaluations may also be delayed.

2. 24 juin 2026 à 18:22 UTCmonitoring

   We have rolled back the deploy and ingest service has recovered. There has been an ingest outage from 17:55 - 18:14 UTC. We have also observed an delay for Service Maps.

3. 24 juin 2026 à 18:31 UTCmonitoring

   Triggers, SLOs and Service Maps are recovered. We are continuing to monitoring the Ingest Service

4. 24 juin 2026 à 19:04 UTCresolved

   All services have been fully recovered. Impact window: 17:55–18:17 UTC Regions affected: Primary impact in US. The EU region was affected to a much lesser degree. During this period, the following effects may have occurred: Ingest: Some data was not ingested, resulting in complete or partial data loss for events sent during the window. Triggers: Triggers may have failed to fire within the impact window. SLOs: SLI values across the affected window are skewed by the missing data and may show artificial dips or accelerated budget burn. Service Maps: Maps covering the outage window are incomplete. Services and dependencies may be under-counted, as their traces were not ingested. We apologize for the disruption. Please reach out if you have any questions about how this may have affected your data.

5. 2 juillet 2026 à 20:10 UTCpostmortem

   On June 24, we experienced approximately 30 minutes of severe data ingestion degradation in Honeycomb’s US and EU instances. During this degradation, Honeycomb rejected a significant percentage of inbound telemetry, and customers would have seen up to a half-hour gap in ingested telemetry. Additionally, during this same time window, customers would have experienced data processing degradation and service disruption within Anomaly Detection and Service Maps. A deployment containing a change to how services retrieve dataset schemas into local caches caused a cascading set of failures, resulting in failed remote cache retrievals, and subsequently, a MySQL stampede due to several services falling back to retrieving schemas from the database. This stampede resulted in significant memory utilization growth, causing some services to crash loop with out-of-memory exceptions while retrieving schemas. Customers would have seen 5xx errors from our ingestion APIs when this occurred, because ingestion services were among those that were crash looping. This also included crash looping from services responsible for Anomaly Detection and Service Maps. Right after these service crash loops began, alerts fired for the crashing services, and procedures were run to pin all services back to the last known good build before the breaking change landed. Once services were running the previous deploy’s build, the 5xx error responses from ingestion APIs returned to nominal baseline levels, and services that were crash looping recovered and resumed normal operation. The underlying issue centered on how dataset schema cache payloads and metadata were serialized to memcached for remote cache retrieval, and how memcached clients deserialize that data before writing it to a local cache. The code change contained a feature flag to toggle the serialization behavior, and backwards-compatibility safeguards for clients deserializing different schema versions from memcached. However, services’ schema deserialization prior to the feature flag flip on did not behave as intended, treating each backwards-compatible schema read as a hard error rather than as a fallback, which subsequently caused every remote schema cache read to fall through to the database. Subsequent analysis and review of the code identified the issue and we have re-deployed this change with a fix along with additional tests. Services now correctly and successfully deserialize schemas from memcached in a safe, backwards-compatible manner.

1. 19 juin 2026 à 16:39 UTCinvestigating

   We are aware of an issue affecting Honeycomb MCP. Write tool functionality may be degraded. Read tools are unaffected.

2. 19 juin 2026 à 17:18 UTCmonitoring

   We are aware of an issue affecting Honeycomb MCP. Write tool functionality may be degraded. Read tools are unaffected.

3. 19 juin 2026 à 17:21 UTCresolved

   MCP Write Tools have been restored. MCP users may need to reconnect to see all available tools.

1. 18 juin 2026 à 19:10 UTCresolved

   Beginning June 17th, enhance-related requests were failing to complete. We've since identified and deployed a fix, and enhance is now fully operational. Thank you for your patience.

1. 17 juin 2026 à 14:01 UTCinvestigating

   We are continuing to investigate intermittent slowness and query failures affecting our Production EU Region. We will provide an update as soon as we have more information.

2. 17 juin 2026 à 15:29 UTCmonitoring

   Querying in our Production EU Region is fully operational. We will continue to monitor for any abnormal behavior.

3. 17 juin 2026 à 21:14 UTCresolved

   We have identified the root cause of the intermittent slowness and query failures affecting our Production EU Region. The issue was triggered by a large volume of dataset deletions that caused elevated database load, resulting in query instability. No data was lost during this incident. Service has been restored. A fix has been applied to help prevent recurrence.

1. 17 juin 2026 à 12:01 UTCinvestigating

   We are currently investigating the cause of slowness and query failures in our Production EU Region.

2. 17 juin 2026 à 12:32 UTCresolved

   The issue is now resolved and querying is back to fully functional.

1. 11 juin 2026 à 23:17 UTCresolved

   Requests to Honeycomb's Query Data and Management APIs in the production-eu1 environment encountered increased error rates between approximately 15:35 and 22:24 UTC. Event ingestion was not affected. The issue has been resolved.

1. 10 juin 2026 à 20:58 UTCinvestigating

   We are investigating an issue with delayed ingest in the EU region. Received events are still being stored, but there may be a delay in event retrieval in queries. SLOs and Trigger evaluations may also be delayed.

2. 10 juin 2026 à 21:28 UTCinvestigating

   Queries should no longer be delayed. SLOs and Trigger evaluations remain impacted.

3. 10 juin 2026 à 21:29 UTCidentified

   The issue has been identified and a fix is being implemented.

4. 10 juin 2026 à 22:02 UTCresolved

   All services are now healthy.

1. 8 juin 2026 à 16:37 UTCinvestigating

   We are currently investigating this issue.

2. 8 juin 2026 à 17:41 UTCresolved

   This incident has been resolved.

1. 3 juin 2026 à 20:50 UTCidentified

   Canvas agent cannot load honeycomb internal tools.

2. 3 juin 2026 à 20:51 UTCresolved

   This incident has been resolved.

1. 21 mai 2026 à 23:22 UTCinvestigating

   We have identified and are working to resolve an issue that is causing query results to return inconsistent results.

2. 22 mai 2026 à 00:49 UTCinvestigating

   Impact from this issue has concluded. For a period of time (different between US and EU instances, noted below), queries spanning data older than the most recent 2 hours with certain GROUP / WHERE clauses returned inconsistent results. Data was never lost, and reruns of the same queries will show the previously missing data. US impact times: 21:50 UTC - 23:20 UTC EU impact times: 20:50 UTC - 23:20 UTC

3. 22 mai 2026 à 16:42 UTCresolved

   This is an administrative update, marking the incident as Resolved. There has been no further impact since 23:20UTC on May 21 2026.