Istoricul incidentelor Honeycombio

1. 22 octombrie 2026 la 16:06 UTCidentified

   Am identificat o problemă în cazul în care e-mailuri pentru SLOs, Triggers, și Anomalie Detectie nu sunt trimise. Lucrăm pentru a repara.

2. 22 octombrie 2026 la 17:07 UTCresolved

   Între 03:53 PM UTC la 4:08 PM UTC am văzut e-mail trimite eșecuri ridica în care un număr mic de clienți (10 întreprindere, 8 auto-servire, și 1 plan pro) au fost afectate. Acest lucru a venit la 508 e-mailuri în total, sau ~1% din e-mail nostru de zi cu zi trimite. Lucrăm pentru a ne asigura că acest mod de eroare nu este capabil să se întâmple din nou.

Traducere automată din actualizarea oficială a incidentului.

1. 20 octombrie 2026 la 14:04 UTCinvestigating

   Investigăm în prezent degradarea diferitelor servicii din regiunea noastră americană.

2. 20 octombrie 2026 la 15:18 UTCinvestigating

   Am identificat şi izolat serviciul afectat şi vedem recuperare în execuţie. Procesarea SLO rămâne degradată.

3. 20 octombrie 2026 la 16:26 UTCresolved

   Procesarea SLO a fost complet recuperată. Toate serviciile sunt acum funcţionale.

4. 21 octombrie 2026 la 23:26 UTCpostmortem

   Pe 20 octombrie, am avut parte de aproximativ trei ore de servicii degradate în regiunea SUA. * De la 13:30 la 14:40 UTC, interogare, Honeycomb UI, managementul API, și declanșează înregistrat rate ridicate de latență și eroare, cu cel mai mare impact între 13:55 și 14:10 UTC. În acest timp, este posibil ca clienții să fi experimentat întrebări lente sau eșuate și un IU lent, iar unele alerte de declanșare pot fi întârziate sau omise. * De la 13:26 la aproximativ 16:10 UTC, prelucrarea SLO a fost întârziată, astfel încât datele SLO ar fi putut apărea de la data și alertele de ardere ar fi putut fi întârziate sau omise în acest timp. * De la 13:57 la 14:09 UTC, aproximativ jumătate din cererile pentru ingerarea evenimentului API au primit erori 5xxx, cu un impact mai mic între 13:48 și 13:55 UTC \(1% rata de eroare\) și pentru aproximativ un minut la 14:15 UTC \(1,9% rata de eroare\). Telemetria respinsă în aceste perioade nu a fost ingerată decât dacă expeditorul a reuşit să o refacă. Clienții pot vedea lacune în datele lor pentru aceste perioade, inclusiv în declanșatori și SLO care acoperă. Inginerii noştri de gardă au fost prima dată chemaţi la 13:43 UTC de o alertă despre declanşatori care nu funcţionează la timp, şi ne-am extins răspunsul la incidentele interne pe măsură ce au urmat alte alerte. Ancheta noastră a constatat că baza de date primară a CPU a fost saturată de un număr mare de interogări citite pe termen lung. Am efectuat o eroare de bază de date pentru a elibera încărcătura. Acest lucru a uşurat pe scurt presiunea, dar aceleaşi întrebări au reapărut curând pe noul primar, aşa că nu a rezolvat problema. Apoi am redus sarcina bazei de date prin încheierea acestor întrebări și întreruperea temporară a procesării SLO, care a restaurat celelalte servicii afectate. Odată ce un timeout de bază de date a fost în vigoare pe interogarea responsabilă, am reluat procesarea SLO, care apoi prins, și am reparat datele istorice SLO. Aceste intrebari au venit de la un cec de procesare nostru SLO ruleaza ori de cate ori se schimba setările unui mediu Honeycomb. În majoritatea cazurilor, se termină în câteva milisecunde. Pentru 0.1% din mediile noastre cu un număr neobişnuit de mare de OSL şi câmpuri calculate, baza de date a rulat-o într-un mod foarte ineficient, şi o actualizare de rutină la setările unui astfel de mediu a făcut verificarea prea lentă pentru a fi finalizată vreodată. Aceste întrebări au continuat să curgă după expirarea termenului serviciului solicitant, iar încercările repetate au mărit sarcina pe baza de date împărtășită de mai multe servicii. Pentru a preveni acest lucru să se întâmple din nou, în plus față de timeout de bază de date, am schimbat modul în care baza de date execută interogarea pentru medii ca aceasta, care a adus timpul său de rulare în jos de la minute la câteva milisecunde. De asemenea, ne-am ajustat pragurile de alertă pentru a ne asigura că un inginer de gardă este informat cu privire la modificările viitoare ale încărcăturii bazei de date.

Traducere automată din actualizarea oficială a incidentului.

1. 20 octombrie 2026 la 17:07 UTCresolved

   De la 13:57 la 14:09 UTC, ingerarea de evenimente în mediul de producție al lui Honeycomb din SUA a fost degradată de un incident concomitent. În timpul acestei ferestre, aproximativ 53% din evenimentele primite au primit erori de 5xx.

Traducere automată din actualizarea oficială a incidentului.

1. 21 august 2026 la 15:21 UTCidentified

   Canvas nu se încarcă pentru clienții din SUA și din regiunile UE și am identificat ceea ce credem că este cauza și dezvoltăm o soluție.

2. 21 august 2026 la 15:25 UTCmonitoring

   Am implementat fix și se vede recuperarea funcționalității normale Canvas.

3. 21 august 2026 la 15:59 UTCresolved

   Acest incident a fost rezolvat.

Traducere automată din actualizarea oficială a incidentului.

1. 10 august 2026 la 13:01 UTCmonitoring

   De la 11:36UTC la 12:43UTC, întrebări în SUA1 care citesc date mai vechi returnate erori sau expirate. Interogările asupra datelor recente nu au fost afectate şi nu se pierde nicio telemetrie. Problema a fost identificată şi există o soluţie. În prezent monitorizăm situația pentru a confirma rezoluția.

2. 10 august 2026 la 20:35 UTCresolved

   Fix este în vigoare și am confirmat rezoluția. Interogările şi SLO-urile procesează normal.

Traducere automată din actualizarea oficială a incidentului.

1. 31 iulie 2026 la 15:42 UTCresolved

   Între 10:30 și 11:00 AM EDT, am experimentat eșecuri ridicate interogare și încetinire. Impactul s-a diminuat şi în prezent investigăm şi monitorizăm situaţia.

2. 21 august 2026 la 13:18 UTCpostmortem

   Incepand de la 9:50 AM Central Pe 31 iulie am primit alerte despre interogarea sănătăţii şi latenţei. Cauza a fost în cele din urmă urmărită până la un conflict de doi factori diferiți. În primul rând, am introdus lambda Managed Tribunals \ (ELMI\) în arhitectura noastră de interogare, care se comportă similar cu clasicul Lambdas în multe moduri și a fost introdus ca parte a muncii în jurul interogării îmbunătățirilor de performanță cu scopul unei experiențe mai bune și mai rapide a utilizatorilor. Din păcate, o diferenţă între clasicii Lambdas şi cei de la MIM descoperiţi de noi este că 15 minute de oprire dură a clasicilor lambdas nu mai există pe LMI, ceea ce înseamnă că anumite ipoteze construite în sistemul nostru de interogare nu mai sunt valabile. La momentul incidentului, noua noastră caracteristică Canvas conducea loturi de întrebări pentru un client care ar trebui să aibă o pauză de un minut. Această pauză nu a fost comunicată corect la Lambda, și în timp ce cu Lambdas clasice sarcina ar tăia automat la 15 minute, noile LMI nu au fost aplicarea acestui tip de mecanism de siguranță. Ca urmare, unele întrebări mari au fost difuzate timp de până la 30 de minute, de conducere până latență interogare peste bord și rezultând în erori pentru utilizatorii care încearcă să ruleze întrebări noi. Sistemul s-a recuperat la 10:10 AM CT, 20 de minute mai târziu, când marile întrebări au fost eliminate, dar am continuat să investigăm cauza incidentului. Odată ce am identificat această slăbiciune în arhitectura noastră de interogare am început să lucrăm să o reparăm și să prevenim din nou același incident. Am trimis toate incidentele asociate.

Traducere automată din actualizarea oficială a incidentului.

1. 27 iulie 2026 la 13:13 UTCinvestigating

   Vedem declanşări intermitente care eşuează în regiunea UE. Investigăm în mod activ cauza.

2. 27 iulie 2026 la 13:52 UTCinvestigating

   Continuăm să vedem probleme cu declanșatorii și observăm, de asemenea, probleme legate de interogare. Investigăm cauza ambelor.

3. 27 iulie 2026 la 16:01 UTCmonitoring

   Am identificat sursa problemei, am aplicat o fixare temporară și lucrăm la o fixare permanentă. Continuăm să monitorizăm situaţia.

4. 27 iulie 2026 la 19:46 UTCmonitoring

   Vedem o regresie în performanţă cu degradare parţială a declanşatorilor şi interogării. Lucrăm pentru a remedia problema.

5. 27 iulie 2026 la 22:51 UTCmonitoring

   Degradarea parțială a fost rezolvată pentru toți clienții, cu excepția celor contactați în mod specific. Lucrăm la măsuri de atenuare, astfel încât să putem restabili pe deplin funcționalitatea de declanșare pentru toată lumea.

6. 28 iulie 2026 la 18:21 UTCmonitoring

   Continuăm să monitorizăm orice alte probleme.

7. 28 iulie 2026 la 18:30 UTCresolved

   Degradarea în interogare și declanșatori a fost rezolvată și ne-am întors la funcționalitate completă.

Traducere automată din actualizarea oficială a incidentului.

1. 2 iulie 2026 la 18:10 UTCinvestigating

   We are currently investigating this issue.

2. 2 iulie 2026 la 18:13 UTCmonitoring

   Clearing the CDN cache appears to have solved the issue.

3. 3 iulie 2026 la 00:31 UTCresolved

   This incident has been resolved.

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

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

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

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

3. 25 iunie 2026 la 20:41 UTCresolved

   This incident has been resolved.

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

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

4. 24 iunie 2026 la 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 iulie 2026 la 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 iunie 2026 la 16:39 UTCinvestigating

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

2. 19 iunie 2026 la 17:18 UTCmonitoring

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

3. 19 iunie 2026 la 17:21 UTCresolved

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

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

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

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

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

2. 17 iunie 2026 la 12:32 UTCresolved

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

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

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

3. 10 iunie 2026 la 21:29 UTCidentified

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

4. 10 iunie 2026 la 22:02 UTCresolved

   All services are now healthy.

1. 8 iunie 2026 la 16:37 UTCinvestigating

   We are currently investigating this issue.

2. 8 iunie 2026 la 17:41 UTCresolved

   This incident has been resolved.

1. 3 iunie 2026 la 20:50 UTCidentified

   Canvas agent cannot load honeycomb internal tools.

2. 3 iunie 2026 la 20:51 UTCresolved

   This incident has been resolved.

1. 21 mai 2026 la 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 la 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 la 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.