Historial de interrupciones de Honeycombio

1. 22 de octubre de 2026 a las 16:06 UTCidentified

   Hemos identificado un problema donde los correos electrónicos para SLOs, Triggers y Anomaly Detection no están enviando. Estamos trabajando para arreglar.

2. 22 de octubre de 2026 a las 17:07 UTCresolved

   Entre las 03:53 PM UTC a las 4:08 PM UTC vimos email enviar fallas elevadas en las que un pequeño número de clientes (10 empresa, 8 autoservicio y 1 plan pro) fueron impactados. Esto llegó a 508 correos electrónicos en total, o ~1% de nuestro correo electrónico diario enviar. Estamos trabajando para asegurar que este modo de falla no pueda suceder de nuevo.

Traducido automáticamente desde la actualización oficial del incidente.

1. 20 de octubre de 2026 a las 14:04 UTCinvestigating

   Actualmente estamos investigando la degradación de diversos servicios en nuestra región estadounidense.

2. 20 de octubre de 2026 a las 15:18 UTCinvestigating

   Hemos identificado y aislado el servicio impactado y estamos viendo recuperación en la ejecución de consultas. El procesamiento de SLO sigue degradado.

3. 20 de octubre de 2026 a las 16:26 UTCresolved

   El procesamiento de SLO se ha recuperado completamente. Todos los servicios son funcionales.

4. 21 de octubre de 2026 a las 23:26 UTCpostmortem

   El 20 de octubre, experimentamos aproximadamente tres horas de servicio degradado en la región estadounidense. * De 13:30 a 14:40 UTC, consulta, la Honeycomb UI, la API de gestión, y los desencadenantes experimentaron altas tasas de latencia y error, con el mayor impacto entre 13:55 y 14:10 UTC. Durante este tiempo, los clientes pueden haber experimentado consultas lentas o fallidas y una UI sluggish, y algunas alertas de disparador pueden haber sido tardías o perdidas. * From 13:26 to approximately 16:10 UTC, SLO processing was delay, so SLO data may have appeared out of date and burn alerts may have been delay or missing during that time. * De 13:57 a 14:09 UTC, aproximadamente la mitad de las solicitudes al evento ingert API recibieron errores 5xx, con menor impacto entre 13:48 y 13:55 UTC \(1% tasa de error\) y por aproximadamente un minuto a 14:15 UTC \(1.9% tasa de error\). La telemetría rechazada durante estos períodos no fue ingerida a menos que el remitente lo retira con éxito. Los clientes pueden ver lagunas en sus datos para esos períodos, incluso en los desencadenantes y SLO que lo cubren. Nuestros ingenieros en la cabina fueron por primera vez a las 13:43 UTC por una alerta sobre los desencadenantes que no se ejecutan a tiempo, y lanzamos nuestra respuesta de incidentes internos como se siguieron otras alertas. Nuestra investigación encontró que la CPU de la base primaria estaba saturada por un gran número de consultas de lectura de larga data. Realizamos una falla en la base de datos para aliviar la carga. Esto suavizó brevemente la presión, pero las mismas consultas pronto reaparecieron sobre la nueva primaria, por lo que no solucionó el problema. Luego reducimos la carga de la base de datos terminando esas consultas y pasando temporalmente el procesamiento de SLO, que restauró los otros servicios afectados. Una vez que el tiempo fuera de la base de datos estaba en marcha en la consulta responsable, reanudamos el procesamiento de SLO, que luego se atrapó, y reparamos datos históricos de SLO. Estas consultas vinieron de un cheque nuestro procesamiento de SLO funciona cada vez que un entorno de Honeycomb cambia la configuración. En una gran mayoría de casos, se completa en unos pocos milisegundos. Para el 0,1% de nuestros entornos con un número inusualmente grande de SLO y campos calculados, sin embargo, la base de datos lo corrió de una manera muy ineficiente, y una actualización rutinaria a uno de esos ajustes hizo que el cheque fuera demasiado lento para completarse. Estas consultas continuaron corriendo después de que el servicio solicitado se agotara, y repetidos intentos aumentaron la carga en una base de datos compartida por varios servicios. Para evitar que esto suceda de nuevo, además del tiempo de salida de la base de datos, cambiamos cómo la base de datos ejecuta la consulta para entornos como este, que trajo su tiempo de funcionamiento de minutos a unos pocos milisegundos. También hemos ajustado nuestros umbrales de alerta para asegurar que un ingeniero en la cabina sea consciente de los futuros cambios de carga de la base de datos rápidamente.

Traducido automáticamente desde la actualización oficial del incidente.

1. 20 de octubre de 2026 a las 17:07 UTCresolved

   De 13:57 a 14:09 UTC, evento ingerido en el entorno de producción de Honeycomb Estados Unidos fue degradado por un incidente concurrente. Durante esta ventana, aproximadamente el 53% de los eventos recibidos recibieron errores de 5xx.

Traducido automáticamente desde la actualización oficial del incidente.

1. 21 de agosto de 2026 a las 15:21 UTCidentified

   Canvas no está cargando para clientes en las regiones de EE.UU. y de la UE y hemos identificado lo que creemos que es la causa y estamos sacando una solución.

2. 21 de agosto de 2026 a las 15:25 UTCmonitoring

   Hemos implementado la solución y estamos viendo la recuperación de la funcionalidad normal de Canvas.

3. 21 de agosto de 2026 a las 15:59 UTCresolved

   Este incidente ha sido resuelto.

Traducido automáticamente desde la actualización oficial del incidente.

1. 10 de agosto de 2026 a las 13:01 UTCmonitoring

   De 11:36UTC a 12:43UTC, las consultas en EE.UU.1 que leyeron datos antiguos devolvieron errores o se timed out. Las consultas sobre datos recientes no se vieron afectadas, y no se está perdiendo telemetría. Se ha identificado la cuestión y se ha establecido una solución. Actualmente estamos monitoreando la situación para confirmar la resolución.

2. 10 de agosto de 2026 a las 20:35 UTCresolved

   La solución está en su lugar y hemos confirmado la resolución. Las consultas y las SLO se procesan normalmente.

Traducido automáticamente desde la actualización oficial del incidente.

1. 31 de julio de 2026 a las 15:42 UTCresolved

   Entre las 10:30 y las 11:00 AM EDT, experimentamos altas fallas de búsqueda y lentitud. El impacto ha disminuido, y actualmente estamos investigando y monitoreando la situación.

2. 21 de agosto de 2026 a las 13:18 UTCpostmortem

   A partir de las 9:50 AM Central Hora del 31 de julio recibimos alertas sobre la búsqueda de salud y latencia. La causa fue finalmente rastreada hasta un choque de dos factores diferentes. En primer lugar, hemos estado introduciendo Lambda Managed Instances \(LMI\) en nuestra arquitectura de consulta, que se comportan de forma similar a las lambdas clásicas de muchas maneras y se habían introducido como parte del trabajo para buscar mejoras de rendimiento con el objetivo de una mejor y más rápida experiencia de usuario. Desafortunadamente, una diferencia entre las lambdas clásicas y los LMIs que descubrimos es la parada dura de 15 minutos de las lambdas clásicas no existe en los LMI, lo que significa que ciertas suposiciones construidas en nuestro sistema de consulta ya no se sostienen. En el momento del incidente, nuestra nueva característica de Canvas estaba ejecutando lotes de consultas para un cliente que debería tener un auto impuesto un minuto de tiempo fuera. Este tiempo no fue comunicado correctamente de vuelta a la lambda, y mientras que con los lambdas clásicos la tarea se cortaría automáticamente a 15 minutos, los nuevos IMC no estaban haciendo cumplir este tipo de mecanismo de seguridad. Como resultado, algunas grandes consultas se estaban ejecutando por hasta 30 minutos, conduciendo latencia de consultas a través de la junta directiva y resultando en errores para los usuarios que intentan realizar nuevas consultas. El sistema se recuperó en 10:10 AM CT, 20 minutos después, cuando las grandes consultas se retiraron, pero continuamos investigando la causa del incidente. Una vez que identificamos esta debilidad en nuestra arquitectura de búsqueda comenzamos a trabajar para arreglarlo y evitar que el mismo incidente vuelva a ocurrir. Hemos enviado todos los seguimientos de incidentes asociados.

Traducido automáticamente desde la actualización oficial del incidente.

1. 27 de julio de 2026 a las 13:13 UTCinvestigating

   Estamos viendo desencadenantes que fallan intermitentemente en la región de la UE. Estamos investigando activamente la causa.

2. 27 de julio de 2026 a las 13:52 UTCinvestigating

   Continuamos viendo problemas con los desencadenantes y también estamos notando problemas con la búsqueda. Estamos investigando por la causa de ambos.

3. 27 de julio de 2026 a las 16:01 UTCmonitoring

   Hemos identificado la fuente de la cuestión, aplicado una solución temporal y estamos trabajando en una solución permanente. Seguimos vigilando la situación.

4. 27 de julio de 2026 a las 19:46 UTCmonitoring

   Estamos viendo una regresión en el rendimiento con degradación parcial de los desencadenantes y la búsqueda. Estamos trabajando para remediar.

5. 27 de julio de 2026 a las 22:51 UTCmonitoring

   La degradación parcial se ha resuelto para todos los clientes excepto para aquellos específicamente contactados. Estamos trabajando en medidas de mitigación para que podamos restaurar plenamente la funcionalidad de los desencadenantes para todos.

6. 28 de julio de 2026 a las 18:21 UTCmonitoring

   Continuamos monitoreando cualquier otro problema.

7. 28 de julio de 2026 a las 18:30 UTCresolved

   La degradación en la búsqueda y los disparadores se ha resuelto y estamos de vuelta a la funcionalidad completa.

Traducido automáticamente desde la actualización oficial del incidente.

1. 2 de julio de 2026 a las 18:10 UTCinvestigating

   We are currently investigating this issue.

2. 2 de julio de 2026 a las 18:13 UTCmonitoring

   Clearing the CDN cache appears to have solved the issue.

3. 3 de julio de 2026 a las 0:31 UTCresolved

   This incident has been resolved.

1. 29 de junio de 2026 a las 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 de junio de 2026 a las 0:47 UTCresolved

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

1. 25 de junio de 2026 a las 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 de junio de 2026 a las 18:31 UTCmonitoring

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

3. 25 de junio de 2026 a las 20:41 UTCresolved

   This incident has been resolved.

1. 24 de junio de 2026 a las 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 de junio de 2026 a las 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 de junio de 2026 a las 18:31 UTCmonitoring

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

4. 24 de junio de 2026 a las 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 de julio de 2026 a las 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 de junio de 2026 a las 16:39 UTCinvestigating

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

2. 19 de junio de 2026 a las 17:18 UTCmonitoring

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

3. 19 de junio de 2026 a las 17:21 UTCresolved

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

1. 18 de junio de 2026 a las 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 de junio de 2026 a las 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 de junio de 2026 a las 15:29 UTCmonitoring

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

3. 17 de junio de 2026 a las 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 de junio de 2026 a las 12:01 UTCinvestigating

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

2. 17 de junio de 2026 a las 12:32 UTCresolved

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

1. 11 de junio de 2026 a las 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 de junio de 2026 a las 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 de junio de 2026 a las 21:28 UTCinvestigating

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

3. 10 de junio de 2026 a las 21:29 UTCidentified

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

4. 10 de junio de 2026 a las 22:02 UTCresolved

   All services are now healthy.

1. 8 de junio de 2026 a las 16:37 UTCinvestigating

   We are currently investigating this issue.

2. 8 de junio de 2026 a las 17:41 UTCresolved

   This incident has been resolved.

1. 3 de junio de 2026 a las 20:50 UTCidentified

   Canvas agent cannot load honeycomb internal tools.

2. 3 de junio de 2026 a las 20:51 UTCresolved

   This incident has been resolved.

1. 21 de mayo de 2026 a las 23:22 UTCinvestigating

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

2. 22 de mayo de 2026 a las 0: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 de mayo de 2026 a las 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.