Honeycombio kesinti geçmişi

1. 22 Ekim 2026 16:06 UTCidentified

   SLOs, Tetikler ve Anomaly Tespit için e-postaların gönderildiği bir sorunu tespit ettik. Biz düzeltmek için çalışıyoruz.

2. 22 Ekim 2026 17:07 UTCresolved

   03:53 PM UTC ile 4:08 PM UTC arasında, e-posta gönderme başarısızlıkları gördük ki, küçük sayıda müşteri (10 işletme, 8 kendini koruma ve 1 pro planı) etkilendi. Bu, günlük e-posta göndermemizin% 508 e-postasına geldi. Bu başarısızlık modunun tekrar gerçekleşemeyeceğinden emin olmak için çalışıyoruz.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 20 Ekim 2026 14:04 UTCinvestigating

   Şu anda ABD bölgemizde çeşitli hizmetlerin bozulmasını araştırıyoruz.

2. 20 Ekim 2026 15:18 UTCinvestigating

   Etkilenen servisi tespit ettik ve izole ettik ve sorgu infazında iyileşme görüyoruz. SLO işleme bozuldu.

3. 20 Ekim 2026 16:26 UTCresolved

   SLO işleme tamamen iyileşti. Tüm hizmetler artık işlevsel.

4. 21 Ekim 2026 23:26 UTCpostmortem

   20 Ekim'de, ABD bölgesinde yaklaşık üç saat süren bir servis yaşadık. * 13:30'dan 14:40 UTC'ye, sorgulama, Honeycomb UI, yönetim API'si ve 13:55 ve 14:10 UTC arasındaki en yüksek etkiye sahip gecikme ve hata oranları deneyimledi. Bu süre zarfında, müşteriler yavaş veya başarısız sorgular ve bir sluggish UI deneyimli olabilir ve bazı uyarılar geç veya kaçırılabilir olabilir. * 13:26'den yaklaşık 16:10 UTC, SLO işleme gecikti, bu yüzden SLO verileri tarih dışında ortaya çıkabilir ve uyarıları bu süre zarfında gecikmiş veya kaçırılabilir. * 13:57'den 14:09 UTC'ye kadar, API'deki duruma gelen isteklerin yaklaşık yarısı 5xx hata aldı, 13:48 ve 13:55 UTC \'nin% (1 hata oranı) ve yaklaşık 14:15 UTC \(1.9% hata oranı) için. Bu dönemdeki telemetri başarılı bir şekilde geri dönmediği sürece yetersiz değildi. Müşteriler, onu kapsayan tetikleyiciler ve SLOs dahil olmak üzere bu dönemlerdeki boşlukları görebilirler. On-call mühendislerimiz ilk sayfa 13:43 UTC'de zaman tükenmemeye dair bir uyarıda bulundular ve iç olayımızı takip eden daha fazla uyarı olarak ortaya çıkardık. Araştırmamız birincil veritabanının CPU'nun uzun süren bir okuma sorguları tarafından doyduğunu buldu. Yükü rahatlatmak için bir veritabanı başarısız yaptık. Bu baskıyı kısaca hafifletti, ancak aynı sorgular yakında yeni birincil üzerinde yeniden ortaya çıktı, bu yüzden sorunu çözmedi. Daha sonra, diğer etkilenen hizmetleri restore eden bu sorguları ve geçici olarak piusing SLO işlemeyi azaltarak veritabanı yükünü azalttık. Bir database-side timeout sorumlu sorguda olduğu zaman, o zaman yakalanan SLO işlemeyi yeniden başlattık ve tarihi SLO verilerini tamir ettik. Bu sorgular SLO işlememizi kontrol etmekten geldi, bir Honeycomb ortamının ayarları değişir. Vakaların büyük bir çoğunluğunda, birkaç milisaniyede tamamlandı. Bununla birlikte, çevrelerimizin% 0.1'i alışılmadık derecede çok sayıda SLOs ve hesaplanan alanlar için, veritabanı çok verimsiz bir şekilde koştu ve bu tür bir ortama rutin bir güncelleme yaptı. Bu sorgular, hizmet zamanından sonra çalışmaya devam etti ve birkaç servis tarafından paylaşılan bir veritabanına tekrarlanan girişimler arttı. Bunun tekrar gerçekleşmesini önlemek için, veritabanının zamanına ek olarak, veritabanının bu gibi ortamlar için sorguyu nasıl işlediğini değiştirdik, bu da birkaç milisaniye yolladı. Ayrıca, bir çağrı mühendisinin gelecekteki veritabanı yükleme değişikliklerinin hızlı bir şekilde farkında olmasını sağlamak için uyarı eşlerimizi ayarlıyoruz.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 20 Ekim 2026 17:07 UTCresolved

   13:57'den 14:09 UTC'ye kadar, Honeycomb'un ABD üretim ortamındaki olay bir eş zamanlı olay tarafından bozuldu. Bu pencerede, gelen olayların yaklaşık% 53'ü 5xx hatası aldı.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 21 Ağustos 2026 15:21 UTCidentified

   Blood, ABD ve AB bölgelerindeki müşteriler için yüklemez ve neden olduğuna inandığımız şeyi tespit ettik ve bir düzeltme yapıyoruz.

2. 21 Ağustos 2026 15:25 UTCmonitoring

   Fix'i kullandık ve normal Kanlı işlevselliğin kurtarılmasını görüyoruz.

3. 21 Ağustos 2026 15:59 UTCresolved

   Bu olay çözüldü.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 10 Ağustos 2026 13:01 UTCmonitoring

   11:36C'den 12:43UTC'ye kadar, eski verileri okuyan ABD1'deki sorgular hata veya zaman bıraktı. Son veriler üzerindeki kuyruklar etkilenmedi ve hiçbir telemetri kaybolmadı. Sorun tespit edildi ve bir düzeltme yerinde. Şu anda kararı doğrulamak için durumu takip ediyoruz.

2. 10 Ağustos 2026 20:35 UTCresolved

   Düzlem yerinde ve doğrulanmış bir karar aldık. Queries ve SLOs normalde işlemektedir.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 31 Temmuz 2026 15:42 UTCresolved

   10:30 ve 11:00 arasında, yüksek sorgulama başarısızlıkları ve yavaşlığı yaşadık. Etki desteklendi ve şu anda durumu araştırıyoruz.

2. 21 Ağustos 2026 13:18 UTCpostmortem

   9:50'de başlayın 31 Temmuz'da zaman, sağlık ve geç kalmışlığı sorgularken uyarı aldık. Sebep sonunda iki farklı faktör çatışmasına kadar takip edildi. İlk olarak, Lambda Managed Instances \(LMI\)'ı birçok yönden klasik kuzulara benzeyen sorgu mimarisimize tanıtıyoruz ve daha iyi ve daha hızlı bir kullanıcı deneyiminin hedefiyle yapılan performans iyileştirmelerinin bir parçası olarak tanıtıldık. Ne yazık ki, keşfettiğimiz klasik kuzular ve LMIs arasında bir fark, klasik kuzuların 15 dakikalık zor durağı LMIs üzerinde mevcut değildir, bu da sorgu sistemimize inşa edilmiş bazı varsayımların artık yapılmadığı anlamına gelir. Olay zamanında, yeni Kanarya özelliği, bir dakika zaman önce kendi kendine dayatılan bir müşteri için sorguları topluca çalıştırıyordu. Bu sefer kuzuya düzgün bir şekilde iletişim kurmadı ve klasik kuzularla görev 15 dakika içinde otomatik olarak kesecekti, yeni LMIs bu tür güvenlik mekanizmasına dayanamadı. Sonuç olarak, bazı büyük sorgular 30 dakikaya kadar sürüyordu, gemideki gecikme gecikmeleri sürüyor ve kullanıcıların taze sorguları çalıştırmaya çalıştığı hatalarla sonuçlanıyordu. Sistem 10:10 AM CT, 20 dakika sonra, büyük sorgular temizlendiğinde, ancak olayın nedenini araştırmaya devam ettik. Bu zayıflığı sorgu mimarisimizde tespit ettikten sonra, onu düzeltmeye ve aynı olayı tekrar ortaya çıkarmaya başladık. Tüm ilişkili olayı takip ettik.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 27 Temmuz 2026 13:13 UTCinvestigating

   AB bölgesinde sürekli olarak başarısız olan tetikleyicileri görüyoruz. Davayı aktif olarak araştırıyoruz.

2. 27 Temmuz 2026 13:52 UTCinvestigating

   İnsanları tetikleyicilerle görmeye devam ediyoruz ve sorgulama ile ilgili sorunlar da değildir. İkimizin nedeni için araştırıyoruz.

3. 27 Temmuz 2026 16:01 UTCmonitoring

   Sorunun kaynağını tespit ettik, geçici bir düzeltme uyguladık ve kalıcı bir düzeltme üzerinde çalışıyoruz. Durumu izlemeye devam ediyoruz.

4. 27 Temmuz 2026 19:46 UTCmonitoring

   Her iki tetikleyicinin kısmi bozulması ve sorgulanması ile performanstaki bir regresyon görüyoruz. Biz remediate için çalışıyoruz.

5. 27 Temmuz 2026 22:51 UTCmonitoring

   Kısmi bozulma, özellikle temas dışında tüm müşteriler için çözüldü. Ayrılma önlemleri üzerinde çalışıyoruz, böylece herkes için işlevselliği tamamen restore edebiliriz.

6. 28 Temmuz 2026 18:21 UTCmonitoring

   Daha fazla sorun için izlemeye devam ediyoruz.

7. 28 Temmuz 2026 18:30 UTCresolved

   Sorgulama ve tetikleyicilerdeki bozulma çözüldü ve tam işlevsellik için geri döndük.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 2 Temmuz 2026 18:10 UTCinvestigating

   We are currently investigating this issue.

2. 2 Temmuz 2026 18:13 UTCmonitoring

   Clearing the CDN cache appears to have solved the issue.

3. 3 Temmuz 2026 00:31 UTCresolved

   This incident has been resolved.

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

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

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

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

3. 25 Haziran 2026 20:41 UTCresolved

   This incident has been resolved.

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

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

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

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

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

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

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

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

2. 17 Haziran 2026 12:32 UTCresolved

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

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

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

3. 10 Haziran 2026 21:29 UTCidentified

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

4. 10 Haziran 2026 22:02 UTCresolved

   All services are now healthy.

1. 8 Haziran 2026 16:37 UTCinvestigating

   We are currently investigating this issue.

2. 8 Haziran 2026 17:41 UTCresolved

   This incident has been resolved.

1. 3 Haziran 2026 20:50 UTCidentified

   Canvas agent cannot load honeycomb internal tools.

2. 3 Haziran 2026 20:51 UTCresolved

   This incident has been resolved.

1. 21 Mayıs 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 Mayıs 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 Mayıs 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.