История сбоев Honeycombio

1. 22 октября 2026 г. в 16:06 UTCidentified

   Мы выявили проблему, когда электронные письма для SLO, Triggers и Anomaly Detection не отправляются. Мы работаем над исправлением.

2. 22 октября 2026 г. в 17:07 UTCresolved

   Между 03:53 PM UTC и 4:08 PM UTC мы увидели, что сбои в отправке электронной почты увеличились, что повлияло на небольшое количество клиентов (10 предприятий, 8 самообслуживания и 1 профессиональный план). Это составило 508 писем, или около 1% от нашей ежедневной рассылки. Мы работаем над тем, чтобы этот режим не смог повториться.

Автоматический перевод официального обновления инцидента.

1. 20 октября 2026 г. в 14:04 UTCinvestigating

   В настоящее время мы расследуем деградацию различных услуг в нашем регионе.

2. 20 октября 2026 г. в 15:18 UTCinvestigating

   Мы идентифицировали и изолировали затронутый сервис и наблюдаем восстановление при выполнении запросов. Обработка SLO остается деградированной.

3. 20 октября 2026 г. в 16:26 UTCresolved

   Обработка SLO полностью восстановлена. Сейчас все сервисы функционируют.

4. 21 октября 2026 г. в 23:26 UTCpostmortem

   20 октября мы пережили примерно три часа деградированной службы в регионе США. * С 13:30 до 14:40 UTC, запрос, интерфейс Honeycomb, API управления и триггеры испытали повышенную задержку и частоту ошибок, с самым высоким воздействием между 13:55 и 14:10 UTC. В течение этого времени клиенты могли испытывать медленные или неудавшиеся запросы и вялый пользовательский интерфейс, а некоторые триггерные оповещения могли быть опозданы или пропущены. С 13:26 до примерно 16:10 UTC обработка SLO задерживалась, поэтому данные SLO могли оказаться устаревшими, а оповещения о выгорании могли быть задержаны или пропущены в течение этого времени. * С 13:57 до 14:09 UTC около половины запросов к событию, проглотившему API, получили ошибки 5xx, с меньшим воздействием между 13:48 и 13:55 UTC \(1% частоты ошибок\) и примерно в течение минуты в 14:15 UTC \(1,9% частоты ошибок\). Телеметрия, отвергнутая в течение этих периодов, не была проглочена, если отправитель не перепробовал ее. Клиенты могут видеть пробелы в своих данных за эти периоды, в том числе в триггерах и SLO, которые покрывают их. Наши инженеры по вызову были впервые опрошены в 13:43 UTC оповещением о том, что триггеры не работают вовремя, и мы расширили нашу внутреннюю реакцию на инциденты. Наше исследование показало, что процессор первичной базы данных был насыщен большим количеством длительных запросов на чтение. Мы выполнили отказ базы данных, чтобы облегчить нагрузку. Это ненадолго ослабило давление, но те же самые запросы вскоре снова появились на новом праймериз, поэтому он не решил проблему. Затем мы уменьшили нагрузку на базу данных, прекратив эти запросы и временно приостановив обработку SLO, что восстановило другие затронутые службы. После того, как в ответном запросе был установлен тайм-аут на стороне базы данных, мы возобновили обработку SLO, которая затем догнала, и восстановили исторические данные SLO. Эти запросы поступали от проверки, которую выполняет наша обработка SLO при изменении настроек среды Honeycomb. В подавляющем большинстве случаев он завершается за несколько миллисекунд. Однако для 0,1% наших сред с необычайно большим количеством SLO и расчетных полей база данных работала очень неэффективно, и обычное обновление одной из настроек такой среды делало проверку слишком медленной, чтобы когда-либо завершить. Эти запросы продолжали выполняться после того, как запрашиваемая услуга была отсрочена, и повторные попытки увеличили нагрузку на базу данных, разделяемую несколькими службами. Чтобы это не повторилось, в дополнение к тайм-ауту на стороне базы данных мы изменили способ выполнения запроса для таких сред, как эта, что сократило время выполнения с минут до нескольких миллисекунд. Мы также скорректировали пороги оповещения, чтобы инженер по вызову был осведомлен о будущих изменениях загрузки базы данных.

Автоматический перевод официального обновления инцидента.

1. 20 октября 2026 г. в 17:07 UTCresolved

   С 13:57 до 14:09 UTC, событие, проглотившее в производственной среде Honeycomb в США, было ухудшено одновременным инцидентом. Во время этого окна примерно 53% входящих событий получили ошибки 5xx.

Автоматический перевод официального обновления инцидента.

1. 21 августа 2026 г. в 15:21 UTCidentified

   Canvas не загружается для клиентов в регионах США и ЕС, и мы определили, что, по нашему мнению, является причиной.

2. 21 августа 2026 г. в 15:25 UTCmonitoring

   Мы внедрили исправление и наблюдаем восстановление нормальной функциональности Canvas.

3. 21 августа 2026 г. в 15:59 UTCresolved

   Этот инцидент был урегулирован.

Автоматический перевод официального обновления инцидента.

1. 10 августа 2026 г. в 13:01 UTCmonitoring

   С 11:36UTC до 12:43UTC запросы в US1, которые считывали старые данные, возвращали ошибки или отсчитывали время. Запросы о последних данных не были затронуты, и телеметрия не теряется. Проблема была выявлена, и исправление на месте. В настоящее время мы следим за ситуацией, чтобы подтвердить резолюцию.

2. 10 августа 2026 г. в 20:35 UTCresolved

   У нас есть исправление, и мы подтвердили решение. Запросы и SLO обрабатываются нормально.

Автоматический перевод официального обновления инцидента.

1. 31 июля 2026 г. в 15:42 UTCresolved

   Между 10:30 и 11:00 утра по восточному времени мы испытывали повышенные сбои в запросах и медлительность. Последствия смягчились, и в настоящее время мы изучаем и отслеживаем ситуацию.

2. 21 августа 2026 г. в 13:18 UTCpostmortem

   Старт в 9:50 AM Central 31 июля мы получили оповещения о запросе о здоровье и задержке. В конечном итоге причина была выслежена до столкновения двух различных факторов. Во-первых, мы внедряем Lambda Managed Instances \(LMI\) в нашу архитектуру запросов, которая во многом похожа на классические лямбда и была введена в рамках работы по улучшению производительности запросов с целью лучшего и более быстрого взаимодействия с пользователем. К сожалению, разница между классическими лямбдами и LMI, которую мы обнаружили, заключается в том, что 15-минутная жесткая остановка классических лямбда не существует на LMI, что означает, что определенные предположения, встроенные в нашу систему запросов, больше не удерживаются. Во время инцидента наша новая функция Canvas запускала пакеты запросов для клиента, которые должны были накладываться на одну минуту. Этот тайм-аут не был должным образом передан обратно в лямбду, и, хотя с классическими лямбдами задача автоматически отключалась через 15 минут, новые LMI не обеспечивали такого рода механизм безопасности. В результате некоторые большие запросы работали до 30 минут, увеличивая задержку запросов по всем направлениям и приводя к ошибкам для пользователей, пытающихся запустить новые запросы. Система восстановилась к 10:10 утра по восточному времени, 20 минут спустя, когда большие запросы были удалены, но мы продолжали расследовать причину инцидента. Как только мы определили эту слабость в нашей архитектуре запросов, мы начали работать над ее исправлением и предотвращением повторения того же инцидента. Мы отправили все связанные с этим инциденты.

Автоматический перевод официального обновления инцидента.

1. 27 июля 2026 г. в 13:13 UTCinvestigating

   Мы видим, что триггеры периодически терпят неудачу в регионе ЕС. Мы активно расследуем причину.

2. 27 июля 2026 г. в 13:52 UTCinvestigating

   Мы продолжаем видеть проблемы с триггерами и также замечаем проблемы с запросами. Мы расследуем причину обоих.

3. 27 июля 2026 г. в 16:01 UTCmonitoring

   Мы определили источник проблемы, применили временное исправление и работаем над постоянным исправлением. Мы продолжаем следить за ситуацией.

4. 27 июля 2026 г. в 19:46 UTCmonitoring

   Мы наблюдаем регресс в производительности с частичной деградацией как триггеров, так и запросов. Мы работаем над восстановлением.

5. 27 июля 2026 г. в 22:51 UTCmonitoring

   Частичное ухудшение было устранено для всех клиентов, за исключением тех, с кем конкретно связывались. Мы работаем над мерами по смягчению последствий, чтобы мы могли полностью восстановить функциональность триггера для всех.

6. 28 июля 2026 г. в 18:21 UTCmonitoring

   Мы продолжаем отслеживать любые дополнительные проблемы.

7. 28 июля 2026 г. в 18:30 UTCresolved

   Деградация запросов и триггеров была решена, и мы вернулись к полной функциональности.

Автоматический перевод официального обновления инцидента.

1. 2 июля 2026 г. в 18:10 UTCinvestigating

   We are currently investigating this issue.

2. 2 июля 2026 г. в 18:13 UTCmonitoring

   Clearing the CDN cache appears to have solved the issue.

3. 3 июля 2026 г. в 00:31 UTCresolved

   This incident has been resolved.

1. 29 июня 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 июня 2026 г. в 00:47 UTCresolved

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

1. 25 июня 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 июня 2026 г. в 18:31 UTCmonitoring

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

3. 25 июня 2026 г. в 20:41 UTCresolved

   This incident has been resolved.

1. 24 июня 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 июня 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 июня 2026 г. в 18:31 UTCmonitoring

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

4. 24 июня 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 июля 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 июня 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 июня 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 июня 2026 г. в 17:21 UTCresolved

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

1. 18 июня 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 июня 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 июня 2026 г. в 15:29 UTCmonitoring

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

3. 17 июня 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 июня 2026 г. в 12:01 UTCinvestigating

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

2. 17 июня 2026 г. в 12:32 UTCresolved

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

1. 11 июня 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 июня 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 июня 2026 г. в 21:28 UTCinvestigating

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

3. 10 июня 2026 г. в 21:29 UTCidentified

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

4. 10 июня 2026 г. в 22:02 UTCresolved

   All services are now healthy.

1. 8 июня 2026 г. в 16:37 UTCinvestigating

   We are currently investigating this issue.

2. 8 июня 2026 г. в 17:41 UTCresolved

   This incident has been resolved.

1. 3 июня 2026 г. в 20:50 UTCidentified

   Canvas agent cannot load honeycomb internal tools.

2. 3 июня 2026 г. в 20:51 UTCresolved

   This incident has been resolved.

1. 21 мая 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 мая 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 мая 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.