Honeycombio 장애 기록

1. 2026년 10월 22일 오후 4:06 UTCidentified

   SLOs, Triggers, Anomaly Detection에 대한 이메일이 전송되지 않는 문제가 발견되었습니다. 우리는 해결하기 위해 일하고 있습니다.

2. 2026년 10월 22일 오후 5:07 UTCresolved

   03:53 PM UTC에서 4:08 PM UTC 사이 우리는 이메일이 고객의 작은 수 (10 엔터프라이즈, 8 셀프 서비스 및 1 프로 플랜)이 영향을받은 실패를 보내 보았습니다. 이것은 총 508 이메일에 와서, 또는 우리의 매일 이메일의 ~ 1 %. 우리는 이 실패 형태를 다시 일어날 수 없습니다 지키는 일입니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 10월 20일 오후 2:04 UTCinvestigating

   우리는 현재 우리의 미국 지역에 다양한 서비스의 분해에 투자하고 있습니다.

2. 2026년 10월 20일 오후 3:18 UTCinvestigating

   우리는 영향을받은 서비스를 식별하고 쿼리 실행에서 복구를보고있다. SLO 처리는 degraded 남아 있습니다.

3. 2026년 10월 20일 오후 4:26 UTCresolved

   SLO 가공은 완전히 회복되었습니다. 모든 서비스는 현재 기능입니다.

4. 2026년 10월 21일 오후 11:26 UTCpostmortem

   10 월 20 일, 우리는 미국 지역에서 약 3 시간의 고급 서비스를 경험했습니다. * 13:30에서 14:40 UTC, 쿼리, 허니콤 UI, 관리 API, 트리거는 13:55 및 14:10 UTC 사이 가장 높은 충격과 함께 높은 대기 시간 및 오류율을 경험. 이 시간 동안, 고객은 느리거나 실패한 쿼리 및 슬러기 UI를 경험할 수 있으며, 일부 트리거 경고는 늦거나 놓칠 수 있습니다. * 13 : 26에서 약 16 : 10 UTC까지 SLO 처리가 지연되었으므로 SLO 데이터는 날짜가 나타날 수 있으며 경고가 지연되거나 놓칠 수 있습니다. * 13:57에서 14:09 UTC, 이벤트 ingest API에 대한 요청에 대한 약 절반은 13:48과 13:55 UTC \ (1% 오류율 \) 사이 더 적은 충격과 14:15 UTC \ (1.9% 오류율 \)에서 약 분. 이 기간 동안 방출되는 Telemetry는 sender가 성공적으로 그것을 retried 한 번 소화되지 않았습니다. 고객은 트리거 및 SLOs를 포함한 그 기간 동안 데이터의 격차를 볼 수 있습니다. 우리의 on-call 엔지니어는 13시 43분 UTC에 처음 페이지되었습니다. 트리거에 대한 경고로 시간이 지남에 따라, 우리는 우리의 내부 사건 응답을 더 경고로 회전. 우리의 조사는 1 차적인 데이터베이스의 CPU가 오랫동안 읽는 쿼리의 많은 수에 의해 포화되었다는 것을 발견했습니다. 우리는로드를 구호하기 위해 데이터베이스가 실패했습니다. 이 간단히 압력이 용이하지만, 새로운 차선에 곧 같은 쿼리, 그래서 문제를 해결하지 않았다. 우리는 그 쿼리 및 일시적으로 SLO 처리의 종료에 의해 데이터베이스 부하를 감소, 이는 다른 영향을 복구 서비스. 데이터베이스 측 timeout이 책임있는 쿼리에 배치되면, 우리는 SLO 처리를 재개, 그 후에 붙잡고, 우리는 역사 SLO 데이터를 복구. 이 쿼리는 Honeycomb 환경의 설정이 변경 될 때마다 우리의 SLO 처리 실행을 확인합니다. 대다수의 경우, 그것은 몇 밀리 초에 완료. SLO 및 계산 된 필드의 예외적으로 큰 수를 가진 우리의 환경의 0.1%를 위해, 그러나, 데이타베이스는 매우 효율적인 방법으로 그것을 ran, 그리고 이러한 환경의 설정에 대한 일상적인 업데이트는 너무 느리게 완료. 이 쿼리는 요청 서비스가 중단 된 후 계속 실행되며 반복 된 시도는 여러 서비스에 의해 공유 된 데이터베이스에로드를 증가했습니다. 이 작업을 다시 방지하기 위해 데이터베이스 측 타임 아웃 외에도 데이터베이스가이 것과 같은 환경을 쿼리를 실행하는 방법을 변경했습니다. 몇 밀리 초에 몇 분에서 실행 시간을 가져 왔습니다. 우리는 또한 우리의 경고 문턱을 조정하여 on-call 엔지니어가 미래의 데이터베이스로드 변경을 신속하게 만듭니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 10월 20일 오후 5:07 UTCresolved

   13:57에서 14:09 UTC, Honeycomb의 미국 생산 환경에서의 이벤트는 동시 사건에 의해 평가되었습니다. 이 창 도중, 들어오는 사건의 대략 53%는 5xx 오류를 받았습니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 8월 21일 오후 3:21 UTCidentified

   화포는 미국과 EU 지구에 있는 고객을 위해 적재하지 않으며 우리는 우리가 일으키는 원인이 되고 고침을 구르는 무슨을 확인했습니다.

2. 2026년 8월 21일 오후 3:25 UTCmonitoring

   우리는 수정을 배포하고 일반 캔버스 기능의 복구를보고있다.

3. 2026년 8월 21일 오후 3:59 UTCresolved

   이 사건은 해결되었습니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 8월 10일 오후 1:01 UTCmonitoring

   11:36UTC에서 12:43UTC, 이전 데이터가 오류를 읽거나 중단 된 US1의 쿼리. 최근 데이터에 대한 쿼리는 비결되지 않았고, telemetry는 손실되지 않습니다. 문제가 확인되었습니다. 수정이 일어났습니다. 우리는 현재 상황을 모니터링하여 해결책을 확인합니다.

2. 2026년 8월 10일 오후 8:35 UTCresolved

   수정은 장소에 있고 우리는 확인한 해결책입니다. Queries와 SLOs는 일반적으로 처리됩니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 7월 31일 오후 3:42 UTCresolved

   10:30와 11:00 AM EDT 사이, 우리는 높은 쿼리 실패와 느린 경험. 충격은 편평하고, 우리는 현재 상황을 조사하고 감시하고 있습니다.

2. 2026년 8월 21일 오후 1:18 UTCpostmortem

   오전 9시 50분에서 시작 7 월 31 일 시간에 우리는 건강 및 대기 질의 주위에 경고를 받았습니다. 원인은 결국 두 가지 다른 요인의 충돌로 추적되었습니다. 첫째, 우리는 Lambda Managed Instances \ (LMI \) 우리의 쿼리 아키텍처로 소개되었습니다. 많은 방법에 고전적인 lambdas와 유사하며 더 나은 사용자 경험의 목표와 성능 향상을 쿼리하는 작업의 일부로 소개되었습니다. 불행히도, 우리가 발견한 고전적인 lambdas와 LMIs 사이 다름은 고전적인 lambdas의 15 분 단단한 정지입니다 LMIs에 존재하지 않습니다, 이는 우리의 쿼리 체계로 건설한 특정 가정이 더 이상 붙지 않는 것을 의미합니다. 사건의 시간에, 우리의 새로운 화포 특징은 각자가 1 분 시간을 밖으로 부과되어야 하는 고객을 위한 쿼리의 배치를 실행했습니다. 이 타임 아웃은 제대로 lambda로 다시 통신하지 않았다, 그리고 고전적인 lambdas로 작업은 자동으로 15 분에서 잘라, 새로운 LMIs는 안전 메커니즘의이 종류를 강제하지 않았다. 결과적으로, 일부 큰 쿼리는 최대 30 분 동안 실행되고, 보드를 통해 쿼리 대기 시간을 운전하고 신선한 쿼리를 실행하려고하는 사용자를위한 오류로 결과. 이 시스템은 10 : 10 AM CT, 20 분 후, 큰 쿼리가 제거 될 때, 그러나 우리는 사건의 원인을 조사 계속. 우리는 우리의 쿼리 아키텍처에이 약점을 확인하면 우리는 그것을 수정하고 다시 발생하는 같은 사건을 방지하기 시작했습니다. 우리는 모든 관련 사건을 위로 발송했습니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 7월 27일 오후 1:13 UTCinvestigating

   우리는 EU 지역에서 간헐적으로 실패 한 방아쇠를보고 있습니다. 우리는 적극적으로 원인을 조사하고 있습니다.

2. 2026년 7월 27일 오후 1:52 UTCinvestigating

   우리는 방아쇠를 가진 문제점을 보고 계속하고 또한 조회를 가진 문제점을 주목합니다. 우리는 모두의 원인에 대한 조사입니다.

3. 2026년 7월 27일 오후 4:01 UTCmonitoring

   우리는 문제점의 근원을 확인하고, 임시 고침을 적용하고, 영원한 고침에 일하고 있습니다. 우리는 상황을 모니터링합니다.

4. 2026년 7월 27일 오후 7:46 UTCmonitoring

   우리는 두 방아쇠와 쿼리의 부분 분해와 성능에 대한 회귀를보고 있습니다. 우리는 remediate에 일하고 있습니다.

5. 2026년 7월 27일 오후 10:51 UTCmonitoring

   부분 분해는 모든 고객을 위해 특별히 접촉을 제외하고 해결되었습니다. 우리는 모든 사람에게 방아쇠 기능을 완전히 복원 할 수 있도록 완화 조치에 노력하고 있습니다.

6. 2026년 7월 28일 오후 6:21 UTCmonitoring

   우리는 더 많은 문제를 모니터링하고 있습니다.

7. 2026년 7월 28일 오후 6:30 UTCresolved

   쿼리 및 트리거의 분해는 해결되고 우리는 전체 기능으로 돌아 왔습니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 7월 2일 오후 6:10 UTCinvestigating

   We are currently investigating this issue.

2. 2026년 7월 2일 오후 6:13 UTCmonitoring

   Clearing the CDN cache appears to have solved the issue.

3. 2026년 7월 3일 오전 12:31 UTCresolved

   This incident has been resolved.

1. 2026년 6월 29일 오후 10: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. 2026년 6월 30일 오전 12:47 UTCresolved

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

1. 2026년 6월 25일 오후 6:10 UTCinvestigating

   We are investigating an issue with delayed ingest in the EU region. SLOs and Trigger evaluations may also be delayed.

2. 2026년 6월 25일 오후 6:31 UTCmonitoring

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

3. 2026년 6월 25일 오후 8:41 UTCresolved

   This incident has been resolved.

1. 2026년 6월 24일 오후 6: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. 2026년 6월 24일 오후 6: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. 2026년 6월 24일 오후 6:31 UTCmonitoring

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

4. 2026년 6월 24일 오후 7: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. 2026년 7월 2일 오후 8: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. 2026년 6월 19일 오후 4:39 UTCinvestigating

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

2. 2026년 6월 19일 오후 5:18 UTCmonitoring

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

3. 2026년 6월 19일 오후 5:21 UTCresolved

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

1. 2026년 6월 18일 오후 7: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. 2026년 6월 17일 오후 2: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. 2026년 6월 17일 오후 3:29 UTCmonitoring

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

3. 2026년 6월 17일 오후 9: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. 2026년 6월 17일 오후 12:01 UTCinvestigating

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

2. 2026년 6월 17일 오후 12:32 UTCresolved

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

1. 2026년 6월 11일 오후 11: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. 2026년 6월 10일 오후 8: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. 2026년 6월 10일 오후 9:28 UTCinvestigating

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

3. 2026년 6월 10일 오후 9:29 UTCidentified

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

4. 2026년 6월 10일 오후 10:02 UTCresolved

   All services are now healthy.

1. 2026년 6월 8일 오후 4:37 UTCinvestigating

   We are currently investigating this issue.

2. 2026년 6월 8일 오후 5:41 UTCresolved

   This incident has been resolved.

1. 2026년 6월 3일 오후 8:50 UTCidentified

   Canvas agent cannot load honeycomb internal tools.

2. 2026년 6월 3일 오후 8:51 UTCresolved

   This incident has been resolved.

1. 2026년 5월 21일 오후 11:22 UTCinvestigating

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

2. 2026년 5월 22일 오전 12: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. 2026년 5월 22일 오후 4: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.