Histórico de interrupções do Honeycombio

1. 22 Here 2026 da 16:06 UTCidentified

   Identificamos um problema onde e-mails para SLOs, Triggers e Anomaly Detection não estão enviando. Estamos a trabalhar para consertar.

2. 22 Here 2026 da 17:07 UTCresolved

   Entre 03:53 PM UTC a 4:08 PM UTC vimos o envio de falhas de email elevar em que um pequeno número de clientes (10 empresa, 8 auto-serve, e 1 plano pro) foram impactados. Isso chegou a 508 emails no total, ou ~1% do nosso email diário. Estamos trabalhando para garantir que este modo de falha não seja capaz de acontecer novamente.

Traduzido automaticamente da atualização oficial do incidente.

1. 20 Here 2026 da 14:04 UTCinvestigating

   Atualmente estamos investigando a degradação de vários serviços em nossa região dos EUA.

2. 20 Here 2026 da 15:18 UTCinvestigating

   Identificamos e isolamos o serviço impactado e estamos vendo recuperação na execução da consulta. O processamento de SLO permanece degradado.

3. 20 Here 2026 da 16:26 UTCresolved

   O processamento SLO foi totalmente recuperado. Todos os serviços estão agora funcionais.

4. 21 Here 2026 da 23:26 UTCpostmortem

   Em 20 de outubro, tivemos cerca de três horas de serviço degradado na região dos EUA. * Das 13:30 às 14:40 UTC, consultando, a IU Honeycomb, a API de gerenciamento, e gatilhos experimentaram elevadas taxas de latência e erro, com o maior impacto entre 13:55 e 14:10 UTC. Durante este tempo, os clientes podem ter experimentado consultas lentas ou falhadas e uma UI lenta, e alguns alertas de gatilho podem ter sido atrasados ou perdidos. * Das 13:26 às 16:10 UTC, o processamento da SLO foi atrasado, então os dados da SLO podem ter aparecido desatualizados e os alertas de gravação podem ter sido atrasados ou perdidos durante esse tempo. * De 13:57 a 14:09 UTC, cerca de metade dos pedidos para o evento de ingestão de API recebeu erros 5xx, com menor impacto entre 13:48 e 13:55 UTC \(1% taxa de erro\) e por aproximadamente um minuto em 14:15 UTC \(1,9% taxa de erro\). A telemetria rejeitada durante esses períodos não foi ingerida, a menos que o remetente tenha tentado novamente. Os clientes podem ver lacunas em seus dados para esses períodos, incluindo em gatilhos e SLOs que o cobrem. Nossos engenheiros de plantão foram chamados pela primeira vez às 13:43 UTC por um alerta sobre gatilhos não funcionando a tempo, e nós giramos para cima a nossa resposta interna incidente como mais alertas seguidos. Nossa investigação descobriu que a CPU do banco de dados primário estava saturada por um grande número de consultas de leitura de longo prazo. Realizamos um failover de banco de dados para aliviar a carga. Isso aliviou brevemente a pressão, mas as mesmas questões logo reapareceram na nova primária, por isso não resolveu o problema. Em seguida, reduzimos a carga do banco de dados terminando essas consultas e pausando temporariamente o processamento SLO, que restaurou os outros serviços afetados. Uma vez que um timeout de banco de dados-side foi em vigor na consulta responsável, retomamos o processamento SLO, que então pegou, e reparamos dados históricos SLO. Essas consultas vieram de uma verificação de nosso processamento SLO roda sempre que as configurações de um ambiente Honeycomb mudam. Na grande maioria dos casos, completa-se em poucos milissegundos. Para os 0,1% de nossos ambientes com um número anormalmente grande de SLOs e campos calculados, no entanto, o banco de dados executou-o de uma forma muito ineficiente, e uma atualização de rotina para um desses ambientes fez a verificação muito lenta para sempre. Essas consultas continuaram em execução após o tempo de serviço solicitado, e tentativas repetidas aumentaram a carga em um banco de dados compartilhado por vários serviços. Para evitar que isso aconteça de novo, além do tempo de espera do banco de dados, nós mudamos como o banco de dados executa a consulta para ambientes como este, que levou seu tempo de execução de minutos para alguns milissegundos. Também ajustámos os nossos limiares de alerta para garantir que um engenheiro de chamadas seja informado de futuras alterações na carga da base de dados rapidamente.

Traduzido automaticamente da atualização oficial do incidente.

1. 20 Here 2026 da 17:07 UTCresolved

   De 13:57 a 14:09 UTC, o evento ingerido no ambiente de produção da Honeycomb foi degradado por um incidente concorrente. Durante esta janela, aproximadamente 53% dos eventos recebidos receberam erros de 5xx.

Traduzido automaticamente da atualização oficial do incidente.

1. 21 Eost 2026 da 15:21 UTCidentified

   A Canvas não está a carregar para os clientes das regiões dos EUA e da UE e identificámos aquilo que acreditamos ser a causa e estamos a criar uma solução.

2. 21 Eost 2026 da 15:25 UTCmonitoring

   Temos implantado a correção e estamos vendo a recuperação da funcionalidade normal Canvas.

3. 21 Eost 2026 da 15:59 UTCresolved

   Este incidente foi resolvido.

Traduzido automaticamente da atualização oficial do incidente.

1. 10 Eost 2026 da 13:01 UTCmonitoring

   De 11:36UTC a 12:43UTC, consultas em US1 que leram dados antigos retornaram erros ou cronometraram. Consultas sobre dados recentes não foram afetadas, e nenhuma telemetria está sendo perdida. A questão foi identificada, e uma solução está em vigor. Estamos actualmente a acompanhar a situação para confirmar a resolução.

2. 10 Eost 2026 da 20:35 UTCresolved

   A solução está pronta e confirmamos a resolução. Consultas e SLOs estão processando normalmente.

Traduzido automaticamente da atualização oficial do incidente.

1. 31 Gouere 2026 da 15:42 UTCresolved

   Entre 10:30 e 11:00 EDT, experimentamos elevadas falhas de consulta e lentidão. O impacto diminuiu, e estamos actualmente a investigar e a acompanhar a situação.

2. 21 Eost 2026 da 13:18 UTCpostmortem

   A partir das 9:50 AM Central Tempo no dia 31 de julho recebemos alertas sobre consulta de saúde e latência. A causa foi eventualmente rastreada até um confronto de dois fatores diferentes. Primeiro, temos vindo a introduzir a Lambda Managed instances \(LMI\) na nossa arquitectura de consultas, que se comportam de forma semelhante às lambdas clássicas de muitas maneiras e foram introduzidas como parte do trabalho em torno da consulta de melhorias de desempenho com o objectivo de uma experiência de utilizador melhor e mais rápida. Infelizmente, uma diferença entre lambdas clássicas e LMIs que descobrimos é que a parada dura de 15 minutos de lambdas clássicas não existe em LMIs, o que significa que certas suposições incorporadas no nosso sistema de consulta já não existem. Na época do incidente, nossa nova funcionalidade Canvas estava executando lotes de consultas para um cliente que deve ter um self imposto um minuto de tempo. Este tempo não foi devidamente comunicado à lambda, e enquanto com lambdas clássicas a tarefa seria automaticamente cortada em 15 minutos, os novos LMIs não estavam aplicando este tipo de mecanismo de segurança. Como resultado, algumas grandes consultas foram executadas por até 30 minutos, aumentando a latência da consulta e resultando em erros para usuários tentando executar novas consultas. O sistema foi recuperado às 10:10 AM CT, 20 minutos depois, quando as grandes consultas foram retiradas, mas continuamos investigando a causa do incidente. Uma vez que identificamos essa fraqueza em nossa arquitetura de consulta, começamos a trabalhar para corrigi-la e evitar que o mesmo incidente ocorra novamente. Enviamos todos os acompanhamentos de incidentes associados.

Traduzido automaticamente da atualização oficial do incidente.

1. 27 Gouere 2026 da 13:13 UTCinvestigating

   Estamos a assistir a uma falha intermitente dos gatilhos na região da UE. Estamos a investigar a causa.

2. 27 Gouere 2026 da 13:52 UTCinvestigating

   Continuamos a ver problemas com gatilhos e também estamos observando problemas com consultas. Estamos a investigar pela causa de ambos.

3. 27 Gouere 2026 da 16:01 UTCmonitoring

   Nós identificamos a fonte do problema, aplicamos uma correção temporária, e estamos trabalhando em uma correção permanente. Continuamos a acompanhar a situação.

4. 27 Gouere 2026 da 19:46 UTCmonitoring

   Estamos vendo uma regressão no desempenho com degradação parcial dos gatilhos e consulta. Estamos a trabalhar para remediar.

5. 27 Gouere 2026 da 22:51 UTCmonitoring

   A degradação parcial foi resolvida para todos os clientes, excepto para os especificamente contactados. Estamos trabalhando em medidas de mitigação para que possamos restaurar totalmente a funcionalidade de gatilho para todos.

6. 28 Gouere 2026 da 18:21 UTCmonitoring

   Continuamos monitorando quaisquer outros problemas.

7. 28 Gouere 2026 da 18:30 UTCresolved

   A degradação em consultas e gatilhos foi resolvida e voltamos à funcionalidade completa.

Traduzido automaticamente da atualização oficial do incidente.

1. 2 Gouere 2026 da 18:10 UTCinvestigating

   We are currently investigating this issue.

2. 2 Gouere 2026 da 18:13 UTCmonitoring

   Clearing the CDN cache appears to have solved the issue.

3. 3 Gouere 2026 da 00:31 UTCresolved

   This incident has been resolved.

1. 29 Mezheven 2026 da 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 Mezheven 2026 da 00:47 UTCresolved

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

1. 25 Mezheven 2026 da 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 Mezheven 2026 da 18:31 UTCmonitoring

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

3. 25 Mezheven 2026 da 20:41 UTCresolved

   This incident has been resolved.

1. 24 Mezheven 2026 da 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 Mezheven 2026 da 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 Mezheven 2026 da 18:31 UTCmonitoring

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

4. 24 Mezheven 2026 da 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 Gouere 2026 da 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 Mezheven 2026 da 16:39 UTCinvestigating

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

2. 19 Mezheven 2026 da 17:18 UTCmonitoring

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

3. 19 Mezheven 2026 da 17:21 UTCresolved

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

1. 18 Mezheven 2026 da 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 Mezheven 2026 da 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 Mezheven 2026 da 15:29 UTCmonitoring

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

3. 17 Mezheven 2026 da 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 Mezheven 2026 da 12:01 UTCinvestigating

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

2. 17 Mezheven 2026 da 12:32 UTCresolved

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

1. 11 Mezheven 2026 da 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 Mezheven 2026 da 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 Mezheven 2026 da 21:28 UTCinvestigating

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

3. 10 Mezheven 2026 da 21:29 UTCidentified

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

4. 10 Mezheven 2026 da 22:02 UTCresolved

   All services are now healthy.

1. 8 Mezheven 2026 da 16:37 UTCinvestigating

   We are currently investigating this issue.

2. 8 Mezheven 2026 da 17:41 UTCresolved

   This incident has been resolved.

1. 3 Mezheven 2026 da 20:50 UTCidentified

   Canvas agent cannot load honeycomb internal tools.

2. 3 Mezheven 2026 da 20:51 UTCresolved

   This incident has been resolved.

1. 21 Mae 2026 da 23:22 UTCinvestigating

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

2. 22 Mae 2026 da 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 Mae 2026 da 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.