Historia awarii Honeycombio

1. 22 października 2026 16:06 UTCidentified

   Zidentyfikowaliśmy problem, w którym e-maile dla SLOS, Triggers i Anomaly Detection nie wysyłają. Pracujemy nad naprawą.

2. 22 października 2026 17:07 UTCresolved

   Między 03: 53 PM UTC do 4: 08 PM UTC widzieliśmy e-mail wysłać niepowodzenia podnieść, w którym mała liczba klientów (10 przedsiębiorstw, 8 self-serve, i 1 pro plan) zostały naruszone. Doszło to do 508 e-maili w sumie, lub ~ 1% naszych codziennych e-maili wysłać. Pracujemy nad tym, by ten tryb awarii nie mógł się powtórzyć.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 20 października 2026 14:04 UTCinvestigating

   Obecnie badamy degradację różnych usług w naszym regionie USA.

2. 20 października 2026 15:18 UTCinvestigating

   Zidentyfikowaliśmy i odizolowaliśmy usługę i widzimy powrót do zdrowia podczas wykonywania zapytań. Przetwarzanie SLO pozostaje zdegradowane.

3. 20 października 2026 16:26 UTCresolved

   Przetwarzanie SLO w pełni odzyskane. Wszystkie usługi funkcjonują.

4. 21 października 2026 23:26 UTCpostmortem

   20 października doświadczyliśmy około trzech godzin zdegradowanej służby w regionie USA. * Od 13: 30 do 14: 40 UTC, querying, the Honeycomb UI, the management API, and expectors expected higher latency and error rates, with the most impact between 13: 55 and 14: 10 UTC. W tym czasie klienci mogli doświadczyć powolnych lub nieudanych zapytań i spowolnionego interfejsu użytkownika, a niektóre alarmy wyzwalające mogły być spóźnione lub pominięte. * Od 13: 26 do około 16: 10 UTC przetwarzanie SLO było opóźnione, więc dane SLO mogły pojawić się nieaktualne, a ostrzeżenia o spaleniu mogły być opóźnione lub pominięte w tym czasie. * Od 13: 57 do 14: 09 UTC, około połowa wniosków o przyjęcie zdarzenia otrzymała błędy 5xx, o mniejszym wpływie między 13: 48 a 13: 55 UTC\ (1% poziom błędu\) i przez około minutę o 14: 15 UTC\ (1,9% poziom błędu\). Telemetria odrzucona w tych okresach nie była spożywana, chyba że nadawca pomyślnie spróbował ponownie. Klienci mogą dostrzec luki w swoich danych w tych okresach, w tym w aktywatorach i SLOS, które je obejmują. Nasi inżynierowie na wezwanie po raz pierwszy zostali wezwani o 13: 43 UTC alarmem o wyzwalaczach, które nie działają na czas, a my uruchomiliśmy naszą wewnętrzną reakcję na incydenty w miarę kolejnych alarmów. Nasze śledztwo wykazało, że główny procesor bazy danych był nasycony przez dużą liczbę długotrwałych zapytań. Przeprowadziliśmy awarię bazy danych, by zmniejszyć obciążenie. To pokrótce złagodziło presję, ale te same pytania wkrótce pojawiły się ponownie na nowym podstawowym, więc nie rozwiązał problemu. Następnie zmniejszyliśmy obciążenie bazy danych poprzez zakończenie tych zapytań i tymczasowe wstrzymanie przetwarzania SLO, które przywróciły inne dotknięte usługi. Gdy na odpowiedzialnym zapytaniu wprowadzono licznik czasu po stronie bazy danych, wznowiliśmy przetwarzanie SLO, które następnie nadrobiono i naprawiliśmy historyczne dane SLO. Pytania te pochodzą z czeku, które nasze przetwarzanie SLO przebiega zawsze, gdy zmienia się środowisko środowiska Honeycomb. W większości przypadków kończy się w kilku milisekundach. Dla 0.1% naszych środowisk z niezwykle dużą liczbą SLOS i obliczonych pól, jednak baza danych prowadziła go w bardzo nieefektywny sposób, a rutynowa aktualizacja do jednego z takich ustawień środowiska sprawia, że czek zbyt wolno, aby kiedykolwiek zakończyć. Pytania te kontynuowały się po tym, jak usługa z prośbą została wyłączona, a powtarzające się próby zwiększyły obciążenie bazy danych udostępnionej przez kilka usług. Aby nie dopuścić do tego ponownie, oprócz czasu z boku bazy danych, zmieniliśmy sposób, w jaki baza danych wykonuje zapytanie dla środowisk takich jak ten, co sprowadziło czas biegania z minut do kilku milisekund. Dostosowaliśmy również nasze progi ostrzegawcze, aby upewnić się, że inżynier on-call zostanie szybko poinformowany o przyszłych zmianach obciążenia bazy danych.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 20 października 2026 17:07 UTCresolved

   Od 13: 57 do 14: 09 UTC, wydarzenie spożywane w środowisku produkcyjnym Honeycomb 'a w USA zostało zdegradowane przez równoczesne zdarzenie. Podczas tego okna około 53% zdarzeń przychodzących otrzymało błędy 5xx.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 21 sierpnia 2026 15:21 UTCidentified

   Canvas nie ładuje dla klientów w regionach USA i UE i ustaliliśmy, co uważamy za przyczynę i wprowadzamy rozwiązanie.

2. 21 sierpnia 2026 15:25 UTCmonitoring

   Wprowadziliśmy naprawę i widzimy odzyskiwanie normalnej funkcji Canvas.

3. 21 sierpnia 2026 15:59 UTCresolved

   Ten incydent został rozwiązany.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 10 sierpnia 2026 13:01 UTCmonitoring

   Od 11: 36UTC do 12: 43UTC, zapytań w US1, które odczytywały starsze dane zwracane błędy lub czas. Zapytania dotyczące ostatnich danych nie zostały naruszone i nie utracono telemetrii. Problem został zidentyfikowany i jest na miejscu. Obecnie monitorujemy sytuację w celu potwierdzenia rezolucji.

2. 10 sierpnia 2026 20:35 UTCresolved

   Naprawimy to i potwierdzimy rozdzielczość. Zapytania i SLOS przetwarzają się normalnie.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 31 lipca 2026 15:42 UTCresolved

   Między 10: 30 a 11: 00 EDT doświadczyliśmy wzmożonych niepowodzeń i powolności. Skutki ustąpiły, a obecnie badamy i monitorujemy sytuację.

2. 21 sierpnia 2026 13:18 UTCpostmortem

   Zaczynając od 9: 50 Czas 31 lipca otrzymaliśmy alarmy wokół pytania zdrowia i opóźnienia. Przyczyną było zderzenie dwóch różnych czynników. Po pierwsze, wprowadzamy Lambda Managed Incidences\ (LMI\) do naszej architektury zapytań, które zachowują się podobnie do klasycznych lambdas na wiele sposobów i zostały wprowadzone w ramach pracy wokół pytania o poprawę wydajności w celu lepszego i szybszego doświadczenia użytkownika. Niestety, różnica między klasycznymi lambdasami a LMIs, którą odkryliśmy, polega na tym, że 15-minutowy twardy przystanek klasycznych lambdasów nie istnieje na LMIs, co oznacza, że pewne założenia wbudowane w nasz system querying już nie istnieją. W czasie incydentu, nasza nowsza funkcja Canvas była uruchamiana partie zapytań dla klienta, który powinien mieć własne narzucone minutę. Ten timeout nie został prawidłowo przekazany z powrotem do lambda, a podczas gdy klasyczne lambdas zadanie automatycznie odcięte w 15 minut, nowe LMI nie egzekwowały tego rodzaju mechanizmu bezpieczeństwa. W rezultacie, niektóre duże zapytania działały do 30 minut, prowadząc do opóźnienia zapytania na całym pokładzie i powodując błędy dla użytkowników próbujących uruchomić świeże zapytania. System odzyskał się o 10: 10, 20 minut później, kiedy duże pytania się skończyły, ale nadal badaliśmy przyczynę incydentu. Kiedy zidentyfikowaliśmy tę słabość w naszej ciekawej architekturze, zaczęliśmy pracować nad jej naprawą i powstrzymaniem tego samego incydentu. Wysłaliśmy wszystkie powiązane działania następcze.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 27 lipca 2026 13:13 UTCinvestigating

   W regionie UE mamy do czynienia z wyzwaniami, które niejednokrotnie zawodzą. Aktywnie badamy sprawę.

2. 27 lipca 2026 13:52 UTCinvestigating

   Nadal dostrzegamy problemy z wyzwalaczami, a także zauważamy problemy z pytaniami. Badamy sprawę obu stron.

3. 27 lipca 2026 16:01 UTCmonitoring

   Zidentyfikowaliśmy źródło problemu, zastosowaliśmy tymczasowe rozwiązanie i pracujemy nad trwałym rozwiązaniem. Monitorujemy sytuację.

4. 27 lipca 2026 19:46 UTCmonitoring

   Widzimy regresję w działaniu z częściową degradacją zarówno wyzwalaczy, jak i zapytań. Pracujemy nad naprawą.

5. 27 lipca 2026 22:51 UTCmonitoring

   Częściowa degradacja została rozwiązana dla wszystkich klientów z wyjątkiem tych, z którymi się kontaktowano. Pracujemy nad środkami łagodzącymi, abyśmy mogli w pełni przywrócić wszystkim funkcjonalność wyzwalacza.

6. 28 lipca 2026 18:21 UTCmonitoring

   Nadal monitorujemy wszelkie dalsze problemy.

7. 28 lipca 2026 18:30 UTCresolved

   Degradacja w pytaniu i wyzwalaniu została rozwiązana i wracamy do pełnej funkcjonalności.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 2 lipca 2026 18:10 UTCinvestigating

   We are currently investigating this issue.

2. 2 lipca 2026 18:13 UTCmonitoring

   Clearing the CDN cache appears to have solved the issue.

3. 3 lipca 2026 00:31 UTCresolved

   This incident has been resolved.

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

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

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

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

3. 25 czerwca 2026 20:41 UTCresolved

   This incident has been resolved.

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

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

4. 24 czerwca 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 lipca 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 czerwca 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 czerwca 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 czerwca 2026 17:21 UTCresolved

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

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

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

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

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

2. 17 czerwca 2026 12:32 UTCresolved

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

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

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

3. 10 czerwca 2026 21:29 UTCidentified

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

4. 10 czerwca 2026 22:02 UTCresolved

   All services are now healthy.

1. 8 czerwca 2026 16:37 UTCinvestigating

   We are currently investigating this issue.

2. 8 czerwca 2026 17:41 UTCresolved

   This incident has been resolved.

1. 3 czerwca 2026 20:50 UTCidentified

   Canvas agent cannot load honeycomb internal tools.

2. 3 czerwca 2026 20:51 UTCresolved

   This incident has been resolved.

1. 21 maja 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 maja 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 maja 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.