Honeycombio driftsforstyrrelser

1. 22. oktober 2026 kl. 16.06 UTCidentified

   Vi har identificeret et problem, hvor e-mails til SLO, Triggers og Anomali Detection ikke sender. Vi arbejder på at ordne det.

2. 22. oktober 2026 kl. 17.07 UTCresolved

   Mellem 03: 53 PM UTC til 4: 08 PM UTC så vi e-mail sende fejl hæve, hvor et lille antal kunder (10 virksomheder, 8 selvbetjening, og 1 pro plan) blev påvirket. Dette kom til 508 e-mails i alt, eller ~ 1% af vores daglige e-mail sende. Vi arbejder på at sikre, at denne fejltilstand ikke kan ske igen.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 20. oktober 2026 kl. 14.04 UTCinvestigating

   Vi undersøger i øjeblikket nedbrydningen af forskellige tjenester i vores amerikanske region.

2. 20. oktober 2026 kl. 15.18 UTCinvestigating

   Vi har identificeret og isoleret den ramte tjeneste og ser bedring i forespørgsel udførelse. SLO forarbejdning forbliver nedbrudt.

3. 20. oktober 2026 kl. 16.26 UTCresolved

   SLO-behandling er fuldt genvundet. Alle tjenester er nu funktionelle.

4. 21. oktober 2026 kl. 23.26 UTCpostmortem

   Den 20. oktober oplevede vi omkring tre timers forringet service i den amerikanske region. * Fra 13: 30 til 14: 40 UTC, forespørger, Honeycomb UI, ledelsen API, og udløser oplevet forhøjede latency og fejlrater, med den højeste indvirkning mellem 13: 55 og 14: 10 UTC. I løbet af denne tid, kunder kan have oplevet langsom eller mislykkede forespørgsler og en træg UI, og nogle udløser advarsler kan have været forsinket eller savnet. * Fra 13: 26 til ca. 16: 10 UTC, SLO behandling blev forsinket, så SLO data kan være dukket ud af dato og brænde indberetninger kan være blevet forsinket eller savnet i løbet af dette tidspunkt. * Fra 13: 57 til 14: 09 UTC, omkring halvdelen af anmodninger til begivenheden ingest API modtaget 5xx fejl, med mindre indvirkning mellem 13: 48 og 13: 55 UTC\ (1% fejlprocent\) og i cirka et minut ved 14: 15 UTC\ (1,9% fejlprocent\). Telemetri afvist i disse perioder blev ikke indtaget, medmindre afsenderen held forsøgte det igen. Kunderne kan se huller i deres data for disse perioder, herunder i udløsere og SLO, der dækker det. Vores on-call-ingeniører blev først sendt kl 13: 43 UTC med en advarsel om udløsere ikke kører til tiden, og vi spundet op vores interne hændelse reaktion som yderligere advarsler følges. Vores undersøgelse fandt ud af, at den primære databases CPU var mættet af et stort antal langløbende læseforespørgsler. Vi udførte en database, der skulle lette lasten. Dette kortvarigt lettet presset, men de samme forespørgsler snart dukkede op på den nye primære, så det ikke løse problemet. Vi reducerede derefter databasebelastningen ved at afslutte disse forespørgsler og midlertidigt pauser SLO behandling, som restaurerede de andre berørte tjenester. Når en databank-side timeout var på plads på den ansvarlige forespørgsel, vi genoptaget SLO behandling, som derefter indhentet, og vi repareret historiske SLO data. Disse forespørgsler kom fra en check vores SLO behandling kører, når en Honeycomb miljø indstillinger ændre. I langt de fleste tilfælde, det fuldender i et par millisekunder. For 0,1% af vores miljøer med et usædvanligt stort antal SLO 'er og beregnede felter, dog, databasen kørte det på en meget ineffektiv måde, og en rutinemæssig opdatering til en sådan miljøs indstillinger gjorde checken for langsom til nogensinde at fuldføre. Disse forespørgsler fortsatte med at køre efter den anmodende service timet ud, og gentagne forsøg øget belastningen på en database deles af flere tjenester. For at forhindre dette i at ske igen, ud over database- side timeout, vi ændrede, hvordan databasen udfører forespørgslen for miljøer som denne, som bragte sin runtime ned fra minutter til et par millisekunder. Vi har også justeret vores varslingstærskelværdier for at sikre, at en on-call ingeniør bliver gjort opmærksom på fremtidige database belastning ændringer hurtigt.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 20. oktober 2026 kl. 17.07 UTCresolved

   Fra 13: 57 til 14: 09 UTC, begivenhed indtager i Honeycombs amerikanske produktionsmiljø blev nedbrudt af en samtidig hændelse. I dette vindue modtog ca. 53% af de indgående begivenheder 5xx fejl.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 21. august 2026 kl. 15.21 UTCidentified

   Canvas læsser ikke til kunder i USA 's og EU' s regioner, og vi har identificeret, hvad vi mener er årsagen, og er ved at udrulle et fix.

2. 21. august 2026 kl. 15.25 UTCmonitoring

   Vi har indsat fix og ser inddrivelse af normal Canvas funktionalitet.

3. 21. august 2026 kl. 15.59 UTCresolved

   Denne hændelse er blevet løst.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 10. august 2026 kl. 13.01 UTCmonitoring

   Fra 11: 36UTC til 12: 43UTC, forespørgsler i US1, der læser ældre data returnerede fejl eller timet ud. Forespørgsler om de seneste data blev ikke påvirket, og ingen telemetri går tabt. Problemet er blevet identificeret, og der er et fix på plads. Vi overvåger i øjeblikket situationen for at bekræfte beslutningen.

2. 10. august 2026 kl. 20.35 UTCresolved

   Fixet er på plads, og vi har bekræftet resolution. Forespørgsler og SLO 'er behandles normalt.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 31. juli 2026 kl. 15.42 UTCresolved

   Mellem 10: 30 og 11: 00 EDT, vi oplevede forhøjede forespørgende fejl og langsommelighed. Virkningen er aftaget, og vi undersøger og overvåger i øjeblikket situationen.

2. 21. august 2026 kl. 13.18 UTCpostmortem

   Fra kl. 9.50. Tid den 31. juli modtog vi advarsler omkring forespørgsel sundhed og latency. Årsagen blev til sidst sporet ned til et sammenstød af to forskellige faktorer. For det første har vi introduceret Lambda Managed Substances\ (LMI\) i vores forespørgsel arkitektur, som opfører sig svarende til klassiske lambdas på mange måder og var blevet indført som en del af arbejdet omkring at udspørge forbedringer med det formål at en bedre og hurtigere brugeroplevelse. Desværre, en forskel mellem klassiske lambdas og LMI 'er vi opdagede er den 15 minutters hårde stop af klassiske lambdas ikke findes på LMI' er, hvilket betyder, at visse antagelser indbygget i vores spørgende system ikke længere holdes. På tidspunktet for hændelsen, vores nyere Canvas funktion kørte partier af forespørgsler til en kunde, som skulle have en selv pålagt et minut tid ud. Denne timeout blev ikke korrekt kommunikeret tilbage til lambda, og mens med klassiske lambdas opgaven ville automatisk afskåret på 15 minutter, de nye LMI 'er ikke håndhæve denne form for sikkerhedsmekanisme. Som et resultat, nogle store forespørgsler kørte i op til 30 minutter, kørsel op forespørgsel latency over hele linjen og resulterer i fejl for brugere, der forsøger at køre friske forespørgsler. Systemet inddrives ved 10: 10 CT, 20 minutter senere, når de store forespørgsler ryddet ud, men vi fortsatte med at undersøge årsagen til hændelsen. Når vi har identificeret denne svaghed i vores spørgende arkitektur vi begyndte at arbejde for at løse det og forhindre den samme hændelse i at opstå igen. Vi har sendt alle relaterede hændelsesopfølgning.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 27. juli 2026 kl. 13.13 UTCinvestigating

   Vi ser udløsere, der periodisk svigter i EU-regionen. Vi undersøger sagen aktivt.

2. 27. juli 2026 kl. 13.52 UTCinvestigating

   Vi fortsætter med at se problemer med udløsere og lægger også mærke til problemer med at spørge. Vi undersøger sagen for begge dele.

3. 27. juli 2026 kl. 16.01 UTCmonitoring

   Vi har identificeret kilden til problemet, anvendt en midlertidig rettelse, og arbejder på en permanent rettelse. Vi følger fortsat situationen.

4. 27. juli 2026 kl. 19.46 UTCmonitoring

   Vi ser en regression i ydeevne med delvis nedbrydning af både udløsere og forespørgende. Vi arbejder på at rydde op.

5. 27. juli 2026 kl. 22.51 UTCmonitoring

   Den delvise nedbrydning er blevet løst for alle kunder undtagen dem, der specifikt er kontaktet. Vi arbejder på afbødende foranstaltninger, så vi fuldt ud kan genoprette udløser funktionalitet for alle.

6. 28. juli 2026 kl. 18.21 UTCmonitoring

   Vi fortsætter med at overvåge for yderligere spørgsmål.

7. 28. juli 2026 kl. 18.30 UTCresolved

   Nedbrydningen i spørgsmål og udløsere er blevet løst, og vi er tilbage til fuld funktionalitet.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 2. juli 2026 kl. 18.10 UTCinvestigating

   We are currently investigating this issue.

2. 2. juli 2026 kl. 18.13 UTCmonitoring

   Clearing the CDN cache appears to have solved the issue.

3. 3. juli 2026 kl. 00.31 UTCresolved

   This incident has been resolved.

1. 29. juni 2026 kl. 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. juni 2026 kl. 00.47 UTCresolved

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

1. 25. juni 2026 kl. 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. juni 2026 kl. 18.31 UTCmonitoring

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

3. 25. juni 2026 kl. 20.41 UTCresolved

   This incident has been resolved.

1. 24. juni 2026 kl. 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. juni 2026 kl. 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. juni 2026 kl. 18.31 UTCmonitoring

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

4. 24. juni 2026 kl. 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. juli 2026 kl. 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. juni 2026 kl. 16.39 UTCinvestigating

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

2. 19. juni 2026 kl. 17.18 UTCmonitoring

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

3. 19. juni 2026 kl. 17.21 UTCresolved

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

1. 18. juni 2026 kl. 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. juni 2026 kl. 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. juni 2026 kl. 15.29 UTCmonitoring

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

3. 17. juni 2026 kl. 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. juni 2026 kl. 12.01 UTCinvestigating

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

2. 17. juni 2026 kl. 12.32 UTCresolved

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

1. 11. juni 2026 kl. 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. juni 2026 kl. 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. juni 2026 kl. 21.28 UTCinvestigating

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

3. 10. juni 2026 kl. 21.29 UTCidentified

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

4. 10. juni 2026 kl. 22.02 UTCresolved

   All services are now healthy.

1. 8. juni 2026 kl. 16.37 UTCinvestigating

   We are currently investigating this issue.

2. 8. juni 2026 kl. 17.41 UTCresolved

   This incident has been resolved.

1. 3. juni 2026 kl. 20.50 UTCidentified

   Canvas agent cannot load honeycomb internal tools.

2. 3. juni 2026 kl. 20.51 UTCresolved

   This incident has been resolved.

1. 21. maj 2026 kl. 23.22 UTCinvestigating

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

2. 22. maj 2026 kl. 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. maj 2026 kl. 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.