65 Honeycombio incidents · 2025年1月 — official updates, affected components, duration and resolution details.
SLO、Triggers、Anomaly Detectionのメールが送信されていない問題を特定しました。 修正作業をしております.
間 03:53 PM UTC へ 4:08 PM UTC 小さな数の顧客(10 企業、8 セルフサービス、および 1 のプロプラン)が影響を受けたメールの送信障害が高まりました。 これは、合計で508メールに来ました, または ~1% 私たちの毎日のメールの送信. この故障モードが再び実現できないよう取り組んでおります.
公式のインシデント更新を自動翻訳しています。
現在、米国地域における各種サービスの劣化を調査しています.
インパクトのあるサービスを特定し、分離し、クエリ実行の回復を見ています。 SLO処理は劣化します.
SLO処理は完全に回復しました。 すべてのサービスは機能的です.
10月20日、アメリカ地域に約3時間営業を経験しました。 *13:30から14:40 UTC、問い合わせ、ハニカムUI、管理API、経験豊富な高レイテンシとエラー率をトリガーし、13:55と14:10 UTCの最も影響を受けます。 現時点では、顧客は遅いか、失敗した照会およびsluggish UIを経験し、ある制動機の警報は遅れか逃されたかもしれません。 ※13:26から16:10頃まで、SLO処理が遅れていたため、SLOデータが日付外に出現し、その時にアラートを燃やす可能性があります。 * 13:57から14:09 UTC、イベントのingest APIへのリクエストの約半分が5xxエラーを受信し、13:48と13:55 UTC \(1%の誤差率)と14:15 UTC \(1.9%の誤差率\)の間の影響が少ない。 これらの期間の間に拒否されたテレメトリーは、送信者が正常にそれを取得する限り、摂取されませんでした。 お客様は、そのデータをその期間のギャップを把握することができます。トリガーやSLO など。 オンコールエンジニアが13:43 UTCで初めてページを張っていました。トリガーが実行されていないというアラートで、内部のインシデントレスポンスをさらに警告するようにしました。 当社の調査では、主要なデータベースのCPUが大量に実行された読み取りクエリで飽和していたことがわかりました。 負荷を和らげるためにデータベースの故障を実行しました。 これは簡単に圧力を緩和しました, しかし、同じクエリはすぐに新しい第一次に再登場しました, そう、それは問題を解決しなかった. その後、これらのクエリと一時的にSLO処理を一時停止することにより、データベースの負荷を削減し、他の影響を受けたサービスを復元しました。 データベース側タイムアウトが責任あるクエリに置かれたら、SLO 処理を再開し、その処理を再開し、歴史的な SLO データを修復しました。 これらのクエリは、ハニカム環境の設定が変更されるたびに、SLO処理が実行されていることを確認してください。 大多数の症例では、数ミリ秒で完了します。 当社の環境の0.1%には、SLOや計算されたフィールドがほとんど多くありますが、データベースは非常に非効率的な方法で実行され、そのような環境の設定に対する定期的な更新は、チェックが遅くなるまで完了しました。 これらのクエリは、リクエストサービスがタイムアウトした後に実行され続け、複数のサービスによって共有されたデータベースへの負荷を繰り返された試みが増加しました。 データベース側のタイムアウトに加えて、これを再び起こさないために、データベースがこの1のような環境のクエリを実行する方法を変更しました。これは、数分から数ミリ秒まで実行時間を短縮しました。 また、オンコールエンジニアが将来のデータベース負荷変化を迅速に認識できるように、アラートの閾値を調整しました.
公式のインシデント更新を自動翻訳しています。
13:57 から 14:09 UTC, ハニカムの米国生産環境でのイベントは、同時インシデントによって劣化した. この画面では、着信イベントの約53%が5xxエラーが発生しました.
公式のインシデント更新を自動翻訳しています。
キャンバスは、米国とEU地域の顧客のためにロードされていないし、我々は原因であり、修正を転がしていると信じていることを認識しています.
修正を配備し、通常のキャンバスの機能の回復を見ています.
この事件は解決しました.
公式のインシデント更新を自動翻訳しています。
11:36UTC から 12:43UTC まで、古いデータが返されたエラーやタイムアウトしたデータを読み込み、US1 で問い合わせます。 最近のデータが影響を受けず、テレメトリーは失われません。 問題が特定され、修正が行われます。 現在、状況を監視し、解像度を確認します.
修正は所定の位置におり、解像度を確認しました。 Queries と SLO は正常に処理されます.
公式のインシデント更新を自動翻訳しています。
10時30分から11時00分までの間、高まるクエリーの失敗と低さを経験しました。 影響はさまざまであり、現状を調査・監視しています.
午前9時50分からスタート 7月31日は、健康とレイテンシのクエリに関するアラートを受け取りました。 原因は、最終的に2つの異なる要因の衝突に追跡されました。 まず、ランバダマネージドインスタンス\(LMI\)をクエリアーキテクチャに導入しました。これは、多くの方法で古典的なランバダと同様に動作し、パフォーマンスの改善をクエリする作業の一環として導入されました。 残念ながら、私たちが発見した古典的なランバダとLMIの違いは、古典的なランバダの15分のハードストップは、LMIに存在しません。つまり、私たちのクエリシステムに構築された特定の仮定が保持されていないことを意味します。 インシデントの時、新しいキャンバス機能は、セルフが1分経ち出すべき顧客のクエリのバッチを実行していました。 このタイムアウトは、ラムダに適切に通信されず、古典的なラムダでは、タスクが自動的に15分で切断され、新しいLMIは、この種の安全メカニズムを強化しませんでした。 その結果、最大で30分間大きなクエリが実行され、ボード全体でクエリレイテンシを駆動し、新しいクエリを実行しようとするユーザーのためのエラーが発生しました。 10:10のCTで回復したシステム, 20 分後, 大きいクエリがクリアされたとき, しかし、我々は、事件の原因を調査し続け. クエリーアーキテクチャーでこの弱点を識別したら、修正し、再び同じインシデントを防止するようになりました。 関連するすべてのインシデントをフォローアップしました.
公式のインシデント更新を自動翻訳しています。
EU地域で断続的に失敗するトリガーを見ています。 原因を積極的に調査しています.
トリガーの問題点や、クエリの問題点も把握し続けています。 両者の原因について調査しています.
私たちは、問題のソースを識別しました, 一時的な修正を適用, 永久的な修正に取り組んでいます. 今後も状況を監視し続けます.
トリガーとクエリの両方の部分的な劣化でパフォーマンスの回帰が見られます。 弊社では、リメディアトに取り組んでおります.
特に接触しているもの以外は、部分的な劣化が解決されています。 全員のトリガー機能を完全に復元できるように、緩和対策に取り組んでいます.
今後の問題がないか引き続き監視しています。
クエリとトリガーの劣化が解決され、フル機能に戻ります.
公式のインシデント更新を自動翻訳しています。
We are currently investigating this issue.
Clearing the CDN cache appears to have solved the issue.
This incident has been resolved.
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.
Backfill of the Activity Log events has completed. All events during the affected period should be present.
We are investigating an issue with delayed ingest in the EU region. SLOs and Trigger evaluations may also be delayed.
We are monitoring the situation. Events may have been delayed between 17:53 and 18:04 UTC.
This incident has been resolved.
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.
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.
Triggers, SLOs and Service Maps are recovered. We are continuing to monitoring the Ingest Service
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.
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.
We are aware of an issue affecting Honeycomb MCP. Write tool functionality may be degraded. Read tools are unaffected.
We are aware of an issue affecting Honeycomb MCP. Write tool functionality may be degraded. Read tools are unaffected.
MCP Write Tools have been restored. MCP users may need to reconnect to see all available tools.
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.
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.
Querying in our Production EU Region is fully operational. We will continue to monitor for any abnormal behavior.
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.
We are currently investigating the cause of slowness and query failures in our Production EU Region.
The issue is now resolved and querying is back to fully functional.
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.
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.
Queries should no longer be delayed. SLOs and Trigger evaluations remain impacted.
The issue has been identified and a fix is being implemented.
All services are now healthy.
We are currently investigating this issue.
This incident has been resolved.
Canvas agent cannot load honeycomb internal tools.
This incident has been resolved.
We have identified and are working to resolve an issue that is causing query results to return inconsistent results.
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
This is an administrative update, marking the incident as Resolved. There has been no further impact since 23:20UTC on May 21 2026.
