Störungsverlauf von Honeycombio

1. 22. Oktober 2026 um 16:06 UTCidentified

   Wir haben ein Problem identifiziert, bei dem E-Mails für SLOs, Trigger und Anomalieerkennung nicht gesendet werden. Wir arbeiten daran, es zu reparieren.

2. 22. Oktober 2026 um 17:07 UTCresolved

   Zwischen 03:53 Uhr UTC bis 16:08 Uhr UTC sahen wir E-Mail-Versandfehler, bei denen eine kleine Anzahl von Kunden (10 Unternehmen, 8 Selbstbedienung und 1 Pro-Plan) betroffen waren. Dies ergab insgesamt 508 E-Mails oder ~ 1% unseres täglichen E-Mail-Versands. Wir arbeiten daran, dass sich dieser Fehlermodus nicht wiederholen kann.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 20. Oktober 2026 um 14:04 UTCinvestigating

   Wir untersuchen derzeit die Verschlechterung verschiedener Dienstleistungen in unserer US-Region.

2. 20. Oktober 2026 um 15:18 UTCinvestigating

   Wir haben den betroffenen Dienst identifiziert und isoliert und sehen eine Wiederherstellung in der Abfrageausführung. SLO-Verarbeitung bleibt degradiert.

3. 20. Oktober 2026 um 16:26 UTCresolved

   Die SLO-Verarbeitung ist vollständig wiederhergestellt. Alle Dienste sind jetzt funktionsfähig.

4. 21. Oktober 2026 um 23:26 UTCpostmortem

   Am 20. Oktober erlebten wir ungefähr drei Stunden degradierten Dienstes in der US-Region. * Von 13:30 bis 14:40 UTC, Abfrage, die Honeycomb-Benutzeroberfläche, die Management-API und löst erhöhte Latenz- und Fehlerraten aus, mit den höchsten Auswirkungen zwischen 13:55 und 14:10 UTC. Während dieser Zeit haben Kunden möglicherweise langsame oder fehlgeschlagene Abfragen und eine schleppende Benutzeroberfläche erlebt, und einige Triggeralarme waren möglicherweise verspätet oder wurden verpasst. * Von 13:26 bis ca. 16:10 UTC wurde die SLO-Verarbeitung verzögert, so dass SLO-Daten möglicherweise veraltet sind und Brennwarnungen während dieser Zeit verzögert oder verpasst wurden. * Von 13:57 bis 14:09 UTC erhielt etwa die Hälfte der Anfragen an die Ereignis-Ingest-API 5xx-Fehler mit geringeren Auswirkungen zwischen 13:48 und 13:55 UTC \(1% Fehlerrate \) und für etwa eine Minute um 14:15 UTC \(1,9% Fehlerrate \). Telemetrie, die während dieser zeiträume abgelehnt wurde, wurde nicht aufgenommen, es sei denn, der absender versuchte es erfolgreich. Kunden können Lücken in ihren Daten für diese Zeiträume sehen, einschließlich in Triggern und SLOs, die diese abdecken. Unsere Bereitschaftstechniker wurden zuerst um 13:43 Uhr UTC durch eine Warnung über Trigger, die nicht rechtzeitig laufen, und wir haben unsere interne Reaktion auf Vorfälle ausgelöst, als weitere Warnungen folgten. Unsere Untersuchung ergab, dass die CPU der primären Datenbank durch eine große Anzahl von lang laufenden Leseanfragen gesättigt war. Wir haben ein Datenbank-Failover durchgeführt, um die Last zu entlasten. Dies erleichterte kurzzeitig den Druck, aber die gleichen Anfragen tauchten bald auf der neuen Primärseite wieder auf, so dass das Problem nicht gelöst wurde. Wir reduzierten dann die Datenbankbelastung, indem wir diese Abfragen beendeten und die SLO-Verarbeitung vorübergehend unterbrachen, wodurch die anderen betroffenen Dienste wiederhergestellt wurden. Sobald ein datenbankseitiges Timeout für die verantwortliche Abfrage vorhanden war, haben wir die SLO-Verarbeitung wieder aufgenommen, die dann aufgeholt und historische SLO-Daten repariert wurde. Diese Abfragen stammen aus einer Überprüfung unserer SLO-Verarbeitung, wenn sich die Einstellungen einer Honeycomb-Umgebung ändern. In der überwiegenden Mehrheit der Fälle ist es in wenigen Millisekunden abgeschlossen. Für die 0,1% unserer Umgebungen mit einer ungewöhnlich großen Anzahl von SLOs und berechneten Feldern lief die Datenbank jedoch sehr ineffizient, und eine routinemäßige Aktualisierung der Einstellungen einer solchen Umgebung machte die Überprüfung zu langsam, um sie jemals abzuschließen. Diese Abfragen liefen weiter, nachdem der anfordernde Dienst abgelaufen war, und wiederholte Versuche erhöhten die Belastung einer Datenbank, die von mehreren Diensten geteilt wurde. Um zu verhindern, dass dies erneut passiert, haben wir zusätzlich zum datenbankseitigen Timeout geändert, wie die Datenbank die Abfrage für Umgebungen wie diese ausführt, wodurch die Laufzeit von Minuten auf einige Millisekunden reduziert wurde. Wir haben auch unsere Alarmschwellenwerte angepasst, um sicherzustellen, dass ein Bereitschaftstechniker schnell auf zukünftige Änderungen der Datenbanklast aufmerksam gemacht wird.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 20. Oktober 2026 um 17:07 UTCresolved

   Von 13:57 bis 14:09 UTC wurde die Ereignisaufnahme in der US-Produktionsumgebung von Honeycomb durch einen gleichzeitigen Vorfall beeinträchtigt. Während dieses Fensters erhielten etwa 53% der eingehenden Ereignisse 5xx Fehler.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 21. August 2026 um 15:21 UTCidentified

   Canvas wird nicht für Kunden in den USA und der EU-Region geladen und wir haben identifiziert, was wir für die Ursache halten, und führen einen Fix aus.

2. 21. August 2026 um 15:25 UTCmonitoring

   Wir haben den Fix bereitgestellt und sehen eine Wiederherstellung der normalen Canvas-Funktionalität.

3. 21. August 2026 um 15:59 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 10. August 2026 um 13:01 UTCmonitoring

   Von 11:36 UTC bis 12:43 UTC haben Abfragen in US1, die ältere Daten gelesen haben, Fehler zurückgegeben oder sind ausgefallen. Abfragen über aktuelle Daten waren nicht betroffen, und es geht keine Telemetrie verloren. Das Problem wurde identifiziert und ein Fix ist vorhanden. Wir beobachten derzeit die Situation, um eine Lösung zu bestätigen.

2. 10. August 2026 um 20:35 UTCresolved

   Der Fix ist vorhanden und wir haben eine Lösung bestätigt. Abfragen und SLOs werden normal verarbeitet.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 31. Juli 2026 um 15:42 UTCresolved

   Zwischen 10:30 und 11:00 Uhr EDT erlebten wir erhöhte Abfragefehler und Langsamkeit. Die Auswirkungen haben nachgelassen, und wir untersuchen und beobachten derzeit die Situation.

2. 21. August 2026 um 13:18 UTCpostmortem

   Ab 9:50 Uhr Central Zeit am 31. Juli erhielten wir Warnungen rund um die Abfrage von Gesundheit und Latenz. Die Ursache wurde schließlich auf einen Zusammenstoß zweier verschiedener Faktoren zurückgeführt. Zunächst haben wir Lambda Managed Instances \(LMI\) in unsere Abfragearchitektur eingeführt, die sich in vielerlei Hinsicht wie klassische Lambdas verhalten und als Teil der Arbeit zur Abfrage von Leistungsverbesserungen mit dem Ziel einer besseren und schnelleren Benutzererfahrung eingeführt wurden. Leider ist ein Unterschied zwischen klassischen Lambdas und LMIs, den wir entdeckt haben, der 15-minütige harte Stopp von klassischen Lambdas, der auf LMIs nicht existiert, was bedeutet, dass bestimmte Annahmen, die in unser Abfragesystem eingebaut wurden, nicht mehr gelten. Zum Zeitpunkt des Vorfalls führte unsere neuere Canvas-Funktion Chargen von Anfragen für einen Kunden aus, die eine selbst auferlegte Zeit von einer Minute haben sollten. Dieser Timeout wurde nicht richtig an das Lambda zurück kommuniziert, und während bei klassischen Lambdas die Aufgabe automatisch nach 15 Minuten abgeschnitten würde, setzten die neuen LMIs diese Art von Sicherheitsmechanismus nicht durch. Infolgedessen liefen einige große Abfragen für bis zu 30 Minuten, was die Abfragelatenz auf der ganzen Linie erhöhte und zu Fehlern für Benutzer führte, die versuchten, neue Abfragen auszuführen. Das System erholte sich um 10:10 Uhr CT, 20 Minuten später, als die großen Abfragen ausgeräumt wurden, aber wir untersuchten weiterhin die Ursache des Vorfalls. Nachdem wir diese Schwäche in unserer Abfragearchitektur identifiziert hatten, begannen wir damit, sie zu beheben und zu verhindern, dass derselbe Vorfall erneut auftritt. Wir haben alle damit verbundenen Incident Follow-ups ausgeliefert.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 27. Juli 2026 um 13:13 UTCinvestigating

   Wir sehen, wie in der EU-Region zeitweise Auslöser versagen. Wir untersuchen aktiv die Ursache.

2. 27. Juli 2026 um 13:52 UTCinvestigating

   Wir sehen weiterhin Probleme mit Triggern und bemerken auch Probleme mit der Abfrage. Wir untersuchen die Ursache von beiden.

3. 27. Juli 2026 um 16:01 UTCmonitoring

   Wir haben die Quelle des Problems identifiziert, einen temporären Fix angewendet und arbeiten an einem permanenten Fix. Wir beobachten die Situation weiterhin.

4. 27. Juli 2026 um 19:46 UTCmonitoring

   Wir sehen eine Regression der Leistung mit teilweiser Verschlechterung der beiden Trigger und Abfrage. Wir arbeiten an der Sanierung.

5. 27. Juli 2026 um 22:51 UTCmonitoring

   Die teilweise Degradation wurde für alle Kunden gelöst, mit Ausnahme derjenigen, die speziell kontaktiert wurden. Wir arbeiten an Minderungsmaßnahmen, damit wir die Triggerfunktionalität für alle vollständig wiederherstellen können.

6. 28. Juli 2026 um 18:21 UTCmonitoring

   Wir werden weiterhin auf weitere Probleme achten.

7. 28. Juli 2026 um 18:30 UTCresolved

   Die Verschlechterung des Abfragens und der Trigger wurde behoben und wir sind wieder voll funktionsfähig.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 2. Juli 2026 um 18:10 UTCinvestigating

   We are currently investigating this issue.

2. 2. Juli 2026 um 18:13 UTCmonitoring

   Clearing the CDN cache appears to have solved the issue.

3. 3. Juli 2026 um 00:31 UTCresolved

   This incident has been resolved.

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

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

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

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

3. 25. Juni 2026 um 20:41 UTCresolved

   This incident has been resolved.

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

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

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

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

1. 18. Juni 2026 um 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 um 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 um 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 um 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 um 12:01 UTCinvestigating

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

2. 17. Juni 2026 um 12:32 UTCresolved

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

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

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

3. 10. Juni 2026 um 21:29 UTCidentified

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

4. 10. Juni 2026 um 22:02 UTCresolved

   All services are now healthy.

1. 8. Juni 2026 um 16:37 UTCinvestigating

   We are currently investigating this issue.

2. 8. Juni 2026 um 17:41 UTCresolved

   This incident has been resolved.

1. 3. Juni 2026 um 20:50 UTCidentified

   Canvas agent cannot load honeycomb internal tools.

2. 3. Juni 2026 um 20:51 UTCresolved

   This incident has been resolved.

1. 21. Mai 2026 um 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 um 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 um 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.