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

1. 21 октября 2026 г. в 16:39 UTCinvestigating

   We're investigating connectivity issues affecting some servers in Azure West Europe. We'll post an update as soon as we know more.

2. 21 октября 2026 г. в 17:13 UTCresolved

   Connectivity to servers in southeast Asia has been restored.

1. 20 октября 2026 г. в 07:21 UTCinvestigating

   Мы изучаем проблемы подключения, затрагивающие некоторые серверы в Google Europe-west2. Мы опубликуем обновление, как только узнаем больше.

2. 20 октября 2026 г. в 07:22 UTCinvestigating

   Мы продолжаем расследование этого вопроса.

3. 20 октября 2026 г. в 07:29 UTCinvestigating

   Инцидент ограничен серверами в Европе-Запад2-Б

4. 20 октября 2026 г. в 09:00 UTCmonitoring

   GCE по-прежнему сообщает о проблемах, но мы видим, что некоторые вызовы API увенчались успехом.

5. 20 октября 2026 г. в 12:13 UTCmonitoring

   GCE подтвердила, что перебои в подаче электроэнергии в Европе-Западе2-b вызвали перебои. Проблема с электроэнергией была смягчена, и к 13:00 UTC сегодня ожидается полное восстановление затронутых рабочих нагрузок. Мы продолжаем следить за восстановлением.

6. 20 октября 2026 г. в 12:33 UTCmonitoring

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

7. 20 октября 2026 г. в 13:32 UTCresolved

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

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

1. 9 октября 2026 г. в 13:28 UTCinvestigating

   Мы изучаем проблемы подключения, затрагивающие некоторые серверы в Azure West Europe. Мы опубликуем обновление, как только узнаем больше.

2. 9 октября 2026 г. в 14:39 UTCinvestigating

   Компания Azure осведомлена об этой проблеме и активно исследует ее. Мы опубликуем еще одно обновление, как только узнаем больше.

3. 9 октября 2026 г. в 15:08 UTCidentified

   Компания Azure решила эту проблему. Они сузили проблему до доступности хранения, затрагивающей регион. Их команды активно проводят восстановительные работы на пострадавшей инфраструктуре, продолжая расследование основной причины. Мы отслеживаем прогресс в восстановлении и работаем над восстановлением пострадавших ресурсов.

4. 9 октября 2026 г. в 17:07 UTCmonitoring

   Нам удалось наладить связь с инстанциями Azure в Западной Европе. Большинство инстанций возвращаются и работают. У Azure все еще есть несколько виртуальных машин для решения.

5. 9 октября 2026 г. в 19:27 UTCresolved

   Все экземпляры CloudAMQP работают в Azure West Europe.

6. 12 октября 2026 г. в 14:51 UTCpostmortem

   ** Резюме** 9 октября CloudAMQP потерял связь с подмножеством кластеров в зоне доступности Azure West Europe 2. Одноузловые кластеры в AZ2 больше всего пострадали от инцидента. ** Воздействие** Клиенты не смогли получить доступ к данным или узлам управления, затронутым во время инцидента. Хронология событий Azure. 12:25 UTC 09 октября 2026 года - Мы выявили эту проблему с помощью наших внутренних служб мониторинга предупреждений. 12:29 UTC 09 октября 2026 г. - Началось воздействие на клиента, сбои VM-дисков были обнаружены в пострадавшем блоке хранения в Западной Европе. * 2:30 UTC 09 октября 2026 года - Расследование выявило потерю сердцебиения в нескольких узлах хранения и доменах неисправностей, в результате чего блок масштаба хранения переходит в режим бедствия. 15:32 UTC от 09 октября 2026 года - Мы вывели устройство масштабирования хранилища из режима бедствия, изолировав диски на затронутых серверах хранения, чтобы обеспечить восстановление оставшихся дисков. На этом этапе большинство пострадавших клиентов начали восстанавливаться. 21:00 UTC 09 октября 2026 года - Инженеры Datacenter и Storage продолжили выполнение плана восстановления на нескольких узлах хранения. 23:27 UTC 09 октября 2026 года — Усилия по восстановлению затронутых узлов хранения были успешными, и работа по восстановлению виртуальных дисков продолжалась. Последующие действия по восстановлению включали восстановление на уровне узлов и восстановление затронутых ресурсов хранения. * 03:00 UTC 10 октября 2026 г. – Восстановлена функциональность сервиса, смягчено влияние на клиента. ** Коренная причина** Из-за проблем с платформой Azure пришлось столкнуться с проблемой хранения дисков Azure Virtual Machines в регионе Западной Европы AZ 2. Пострадавшие клиенты, возможно, испытали сбои подключения, неожиданные перезагрузки или вхождение виртуальных машин в несостоявшееся состояние в регионе. ** Резолюция** Доступ к машинам был восстановлен Azure примерно за 3 часа. CloudAMQP удалось восстановить связь с пораженными узлами. Мы продолжали следить за обновлениями Azure, чтобы убедиться, что узлы больше не затронуты.

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

1. 6 октября 2026 г. в 14:37 UTCidentified

   Мы наблюдаем ухудшение сетевого взаимодействия между некоторыми сетями, не относящимися к Azure, и Azure UAE North, вызванное проблемой маршрутизации у поставщика транзитных услуг. Все серверы в регионе работают и обрабатывают сообщения, а мониторинг, метрики и журналы работают как обычно. Клиенты, чьи клиенты подключаются к сетям, затронутым этой проблемой маршрутизации, также могут видеть тайм-ауты соединения. Мы сообщили о проблеме провайдеру и направляем вокруг нее собственный трафик.

2. 6 октября 2026 г. в 15:44 UTCmonitoring

   Маршрутизация вернулась к норме.

3. 6 октября 2026 г. в 15:48 UTCresolved

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

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

1. 26 августа 2026 г. в 13:27 UTCinvestigating

   В настоящее время мы расследуем этот вопрос.

2. 26 августа 2026 г. в 13:28 UTCidentified

   Этот вопрос был определен, и в настоящее время осуществляется исправление.

3. 26 августа 2026 г. в 13:41 UTCmonitoring

   Реализовано исправление, и мы отслеживаем результаты.

4. 26 августа 2026 г. в 13:57 UTCresolved

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

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

1. 24 августа 2026 г. в 23:52 UTCmonitoring

   DigitalOcean в настоящее время испытывает проблемы с API и панелью управления, и вы можете столкнуться с ошибками и более высокой задержкой, пока проблема сохраняется

2. 25 августа 2026 г. в 23:58 UTCresolved

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

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

1. 23 июля 2026 г. в 15:33 UTCinvestigating

   Мы получили различные уведомления о том, что несколько серверов, развернутых на Azure West US, недоступны. По-видимому, это связано с тем, что эта область влияет на 25% серверов.

2. 23 июля 2026 г. в 19:50 UTCmonitoring

   Microsoft Azure подтвердила, что у них возникли проблемы с сетью в западноамериканском регионе. На данный момент большинство серверов работают. Мы продолжим наблюдение в течение следующих часов.

3. 23 июля 2026 г. в 21:48 UTCresolved

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

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

1. 26 июня 2026 г. в 08:38 UTCinvestigating

   We are currently investigating this issue.

2. 26 июня 2026 г. в 09:17 UTCidentified

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

3. 26 июня 2026 г. в 14:22 UTCmonitoring

   A fix has been implemented and we are monitoring the results.

4. 26 июня 2026 г. в 14:44 UTCresolved

   This incident has been resolved.

5. 29 июня 2026 г. в 11:22 UTCpostmortem

   **Summary** Between June 25 and June 26, our monitoring system incorrectly reported some dedicated servers as unreachable and sent "server down" notifications for servers that were in fact operating normally. This was a monitoring-side issue only — no customer servers or services were actually down, and no data or message delivery was affected. **Impact** Affected customers received one or more alerts indicating their dedicated server was down. These alerts were false positives. The servers themselves remained healthy and fully available throughout the incident. **Root cause** Before connecting to a server, our monitoring system performs a network authorization step. A defect in how one component handled a transient network hiccup could leave a monitoring process unable to complete that step, after which it failed to connect to the servers it was responsible for checking. The servers themselves stayed healthy and available throughout — the monitoring process had simply lost its ability to reach them, and reported them as down. **Resolution** We identified the affected monitoring processes, confirmed the root cause in production, and deployed a fix that makes this authorization step resilient to such transient failures and able to recover automatically. After deploying, we monitored the system to confirm that notifications returned to normal. We apologize for the confusion these false notifications may have caused.

1. 30 мая 2026 г. в 22:25 UTCmonitoring

   Between 17:30 and 20:00 UTC on 2026-05-30, our server monitoring system generated a large number of false "server_unreachable" alerts. Clusters were operational and healthy throughout this period — no customer data or message delivery was affected. The alerts were caused by a rolling restart of our monitoring service, during which individual monitoring workers went offline mid-cycle and lost state. This caused the workers to report connection timeouts for servers they could no longer reach — even though those servers were fully healthy. We apologize for any concern this may have caused.

2. 31 мая 2026 г. в 11:29 UTCresolved

   This incident has been resolved.

1. 23 мая 2026 г. в 16:21 UTCinvestigating

   We are investigating connectivity issues affecting some CloudAMQP instances in Azure West Europe. Affected instances may see connection failures or unexpected restarts. The root cause is an ongoing Microsoft Azure platform incident in the West Europe region (started 14:31 UTC, 23 May 2026). Microsoft is investigating.

2. 23 мая 2026 г. в 17:23 UTCresolved

   Resolved — Microsoft has confirmed that the Azure West Europe Virtual Machines incident is resolved. The impact window was 14:09–14:13 UTC on 23 May 2026, during which a limited number of customers may have experienced connection failures or unexpected Virtual Machine restarts. The Azure environment self-healed and the service has been confirmed restored. Affected CloudAMQP instances should now be operating normally.

1. 22 мая 2026 г. в 03:16 UTCinvestigating

   Since around 8pm UTC last night, some metrics are not being forwarded to legacy integration. Prometheus integrations not affected. We are investingating.

2. 22 мая 2026 г. в 04:08 UTCmonitoring

   A fix has been implemented and we are monitoring the results.

3. 22 мая 2026 г. в 04:50 UTCresolved

   This incident has been resolved.

4. 22 мая 2026 г. в 13:52 UTCpostmortem

   # Legacy host metrics integrations degraded Incident window: 2026-05-21 18:37 UTC – 2026-05-22 04:05 UTC \(9h 28m\) Affected service: Legacy metric integrations \(CloudWatch, Datadog, Librato, New Relic, Splunk, Stackdriver\). Host metrics affected, not broker metrics, nor was internal monitoring or console graphs. ## Summary For ~9.5 hours, the service that collects host-level metrics \(CPU, memory, disk, network\) for legacy third-party integrations entered a crash loop and stopped shipping data. ## Root Cause An internal credential-signing service was migrated to a new container runtime the afternoon before. Due to a bug with environment variables the collector could not renew it's credentials. The collector's existing credential remained valid for several hours, so the failure only surfaced when it tried to renew. ## Resolution On-call staff detected the failure early morning, developers helped restore the service and collector recovered at 04:05 UTC. ## Prevention * All services, both signing and collector report failed authentication attempts earlier and with higher severity * Metrics pipeline alarm thresholds was tightened so a similar drop in data triggers alarms faster.

1. 19 мая 2026 г. в 13:21 UTCinvestigating

   We are currently experiencing issues with our backend services handling account and server creation. This does not affect any running customer servers but might delay provisioning new servers.

2. 19 мая 2026 г. в 13:36 UTCidentified

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

3. 19 мая 2026 г. в 13:41 UTCmonitoring

   A fix has been implemented and we are monitoring the results.

4. 19 мая 2026 г. в 13:50 UTCresolved

   This incident has been resolved.

1. 5 мая 2026 г. в 10:23 UTCinvestigating

   We are currently experiencing issues with our backend services handling account and server creation. This does not affect any running customer servers but might delay provisioning new servers.

2. 5 мая 2026 г. в 10:41 UTCmonitoring

   A fix has been implemented and we are monitoring the results.

3. 5 мая 2026 г. в 11:23 UTCmonitoring

   Still seeing slow requests, doing another investigation.

4. 5 мая 2026 г. в 11:34 UTCmonitoring

   Looks like we're back at full performance now.

5. 5 мая 2026 г. в 13:23 UTCresolved

   This incident has been resolved.

1. 3 мая 2026 г. в 19:11 UTCinvestigating

   We are currently investigating this issue.

2. 3 мая 2026 г. в 19:14 UTCidentified

   Servers in Azure West Europe can experience connection issues due to underlying issues at provider. Latest update from Azure "Current Status: We continue to investigate an availability issue caused by a subset of unhealthy backend storage infrastructure supporting Azure Virtual Machines and Azure Direct Drive in West Europe."

3. 4 мая 2026 г. в 01:44 UTCresolved

   This incident has been resolved.

1. 28 апреля 2026 г. в 10:27 UTCinvestigating

   We are currently experiencing issues with our backend services handling account and server creation. This does not affect any running customer servers but might delay provisioning new servers.

2. 28 апреля 2026 г. в 10:49 UTCidentified

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

3. 28 апреля 2026 г. в 10:53 UTCmonitoring

   A fix has been implemented and we are monitoring the results.

4. 28 апреля 2026 г. в 11:05 UTCresolved

   We had an abnormal increase in traffic causing timeouts and slow responses for customer.cloudamqp.com, we increased capacity and are back to normal. This did not affect any running clusters, just provisioning and configuration updates.

1. 24 апреля 2026 г. в 09:36 UTCinvestigating

   We are getting indications of instances being down in Azure region westus. We are investigating the issue.

2. 24 апреля 2026 г. в 11:12 UTCresolved

   This incident has been resolved.

1. 23 апреля 2026 г. в 10:10 UTCinvestigating

   Servers in Azure West US 3 can experience connection issues due to underlying issues at provider. We monitor and will update when we know more.

2. 23 апреля 2026 г. в 10:56 UTCresolved

   This incident has been resolved.

1. 23 апреля 2026 г. в 04:33 UTCinvestigating

   There appears to be an issue regarding sending metrics to all Legacy metrics integrations. Alarms based on broker metrics also got affected. We are currently investigating the issue Prometheus based metrics (Datadog v3 etc) not affected.

2. 23 апреля 2026 г. в 06:53 UTCmonitoring

   A fix has been implemented and we are monitoring the results.

3. 23 апреля 2026 г. в 11:32 UTCresolved

   This incident has been resolved.

4. 24 апреля 2026 г. в 08:38 UTCpostmortem

   Broker metrics and metrics integrations degradation Window: 2026-04-23 03:25 – 05:35 UTC \(2h 10m\) ## Impact Broker metrics \(connections, channels, queues, consumers, message rates, node and netsplit state\) were degraded, progressively dropping until recovery at 05:35 UTC. Downstream effects: * Queue, Consumer, Connection, Channel, Connection flow, and Netsplit alarms: threshold breaches during the window may not have triggered, or triggered late. Alarms already tripped before 03:25 UTC kept their state. * Metrics Integrations \(Datadog, CloudWatch, New Relic, Splunk, Dynatrace, etc.\): delivery of broker metrics was reduced for the duration of the window. Alarms configured on the receiving side may likewise have missed or lagged. Not affected: server metrics \(CPU, memory, disk\) and their corresponding alarms, Notice alarms, broker availability, and the metric graphs shown in the CloudAMQP console \(these use a separate data path and continued to update normally\). ## Timeline \(UTC\) * 03:25 — broker-metrics collection begins degrading * 03:35 — ~30% of broker-metric samples missing * 03:50 — ~50% plateau * 05:25 — collector workers cycled and re-initialised * 05:35 — full throughput restored ## Root cause Broker metrics are polled from each cluster's management HTTP API by a pool of collector workers and published to an internal message bus that both the Alarms service and Metrics Integrations consume from. At 03:25 UTC this service became unresponsive without raising an error. Affected workers silently stopped polling while remaining alive to the platform, so automatic restart did not trigger. On-call staff began investigating around 05:00 UTC; force-restarting the service restored metric flow. The exact trigger has not been identified. Our focus is on ensuring the condition is detected and handled promptly if it recurs. ## What we are changing * Added metrics and alarms specific to this service, with high-urgency paging for on-call. * Reliability improvements in the service itself to detect and restart stalled work. ## What you can do CloudAMQP offers a new generation of metrics integrations based on Prometheus, with a re-engineered pipeline that does not rely on these centralised services — each server forwards data directly to your endpoint. These have been running in production for some time and have proved very reliable. * [https://www.cloudamqp.com/blog/prometheus-metrics-integrations.html](https://www.cloudamqp.com/blog/prometheus-metrics-integrations.html) * [https://www.cloudamqp.com/docs/monitoring\_metrics\_datadog\_v3.html](https://www.cloudamqp.com/docs/monitoring_metrics_datadog_v3.html) * Background: [https://www.cloudamqp.com/blog/decentralized-observability-with-open-telemetry-part-1.html](https://www.cloudamqp.com/blog/decentralized-observability-with-open-telemetry-part-1.html)

1. 15 апреля 2026 г. в 15:32 UTCresolved

   One of our backend components suffered a small outage due to an unexpected full services restart. Connectivity with the servers were broken and service triggered alarms for many clusters. We apologize for the inconvenience. All clusters were operational and healthy within the incident/alarms timespan.

1. 2 апреля 2026 г. в 14:41 UTCidentified

   Customers are experiencing Management UI being unavailable with 502 Bad Gateway. Timeline: - 14:16 UTC -> The issue was identified - 14:30 UTC -> Recent code changes were reverted. No relationship with incident noted.

2. 2 апреля 2026 г. в 14:52 UTCidentified

   The Management UI and brokers are serving traffic normally. You can still use the Management UI by using the Broker URL and properly typing User and Password. The impact is related to our backend service logs into Management UI via CloudAMQP SSO.

3. 2 апреля 2026 г. в 15:07 UTCidentified

   We are continuing to work on a fix for this issue.

4. 2 апреля 2026 г. в 15:12 UTCresolved

   The Management UI SSO shortcut is back to service. Impacted Clusters: All customers with clusters created more than 6 months ago Cause: Some code changes unexpectedly changed the communication schema between our backend services and the SSO component on the clusters. The proxy configuration conflicted with those changes causing the 502 Bad Gateway error to show up. Impact: Only the SSO via CloudAMQP Console was impacted given it required communication with our backend components. The AMQP Clusters were healthy and servicing traffic via both AMQP and HTTP on Management UI and API. Logging into the Management UI via Credentials and all Authentications Backends was functioning normally.