Cloudamqp 장애 기록

1. 2026년 10월 21일 오후 4: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. 2026년 10월 21일 오후 5:13 UTCresolved

   Connectivity to servers in southeast Asia has been restored.

1. 2026년 10월 20일 오전 7:21 UTCinvestigating

   Google europe-west2의 일부 서버에 영향을 미치는 연결 문제를 조사하고 있습니다. 우리는 우리가 더 알고 있기 때문에 업데이트 게시됩니다.

2. 2026년 10월 20일 오전 7:22 UTCinvestigating

   이 문제를 조사하고 있습니다.

3. 2026년 10월 20일 오전 7:29 UTCinvestigating

   Incident는 유럽-서부2-b에서 서버로 제한됩니다

4. 2026년 10월 20일 오전 9:00 UTCmonitoring

   GCE는 여전히 문제보고, 그러나 우리는 일부 API 호출 성공보고있다.

5. 2026년 10월 20일 오후 12:13 UTCmonitoring

   GCE는 유럽-서부2-b의 전력 부족이 붕괴를 초래했다고 확인했습니다. 전력 문제는 mitigated, 및 영향 받은 작업 부하의 전체 복구는 오늘 13시 UTC에 의해 예상됩니다. 우리는 복구를 계속합니다.

6. 2026년 10월 20일 오후 12:33 UTCmonitoring

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

7. 2026년 10월 20일 오후 1:32 UTCresolved

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

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

1. 2026년 10월 9일 오후 1:28 UTCinvestigating

   Azure West Europe의 일부 서버에 영향을 미치는 연결 문제를 조사하고 있습니다. 우리는 우리가 더 알고 있기 때문에 업데이트 게시됩니다.

2. 2026년 10월 9일 오후 2:39 UTCinvestigating

   Azure는 이 문제의 인식이며 적극적인 조사입니다. 우리는 우리가 더 알고 있기 때문에 또 다른 업데이트를 게시 할 것입니다.

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

   Azure는이 문제를 확인했습니다. 그들은 지역에 영향을 미치는 저장 접근성에 대한 문제점을 좁혔습니다. 그들의 팀은 영향을받는 인프라에서 회복 활동을 적극적으로 수행하고 지속적인 원인을 조사합니다. 우리는 복구 진행 상황을 모니터링하고 영향을받는 자원 복원 작업입니다.

4. 2026년 10월 9일 오후 5:07 UTCmonitoring

   Azure West Europe의 인스턴스와 통신을 설정할 수 있습니다. 인스턴스의 주요성은 백업 및 실행입니다. Azure는 여전히 해결하기 위해 VM을 가지고 있습니다.

5. 2026년 10월 9일 오후 7:27 UTCresolved

   모든 CloudAMQP 인스턴스는 Azure West Europe에서 실행됩니다.

6. 2026년 10월 12일 오후 2:51 UTCpostmortem

   ** 일정 ** CloudAMQP는 10월 9일에 Azure West Europe 가용성 Zone 2에서 클러스터의 하위 집합과 연결을 잃었습니다. AZ2의 단일 노드 클러스터는 사건에 가장 영향을 미쳤습니다. ** 중요 ** 고객의 데이터 또는 만지 노드에 접근할 수 없습니다. Azure의 이벤트 타임라인. * 12:25 UTC on 09 10월 2026 – 우리는 우리의 내부 서비스 모니터링 경고를 통해이 문제를 확인. * 12:29 UTC on 09 10월 2026 – 고객 영향은 영향을받는 웨스트 유럽 저장 규모 단위에서 감지 된 VM 디스크 실패와 함께 시작되었습니다. * 2:30 UTC on 09 10월 2026 - 여러 저장 노드와 오류 도메인을 통해 심장 박동의 조사에 따르면 저장 스케일 단위가 경감 모드에서 이동합니다. * 15:32 UTC on 09 10월 2026 - 우리는 남은 디스크의 복구를 가능하게하는 영향받은 저장 서버에 디스크를 고립시키는 과감한 형태에서 저장 가늠자 단위를 가지고 갔습니다. 이 단계에서 가장 영향을받는 고객 중 대부분은 복구를 시작했습니다. * 21:00 UTC on 09 October 2026 - Datacenter 및 Storage 엔지니어는 여러 저장 노드에서 복구 계획을 실행했습니다. * 23:27 UTC on 09 10월 2026 – 영향을받은 저장 노드를 복구하는 노력은 성공적이었고, 가상 디스크를 복구하는 작업이 계속되었습니다. 적격 복구 작업 포함 된 노드 수준의 복구 및 영향을받는 저장 자원의 복원. * UTC on 10 10월 2026 – 서비스 기능 복구, 그리고 고객 영향은 mitigated. ** 루트 원인 ** Azure는 West Europe 지역 AZ 2의 Azure Virtual Machines 스토리지 디스크에 영향을 미치는 플랫폼 문제 경험 충격을 입힌 고객은 지역에 실패한 국가를 입력한 연결 실패, 예상치 못한 재시작 또는 사실상 기계 경험이 있을지도 모릅니다. ** 해결책 ** 기계 접근은 대략 3 시간에 있는 Azure에 의해 복원되었습니다. CloudAMQP는 영향 받은 노드와 통신을 복원할 수 있었습니다. 우리는 Azure에서 업데이트를 모니터링하는 것을 계속하여 노드가 더 이상 영향을 미쳤습니다.

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

1. 2026년 10월 6일 오후 2:37 UTCidentified

   우리는 일부 비-Azure 네트워크와 Azure UAE North (azure-arm ::uaenorth) 사이의 네트워크 연결성을 향상시키고 업스트림 트랜스트 공급자의 라우팅 문제로 인한. 지역에있는 모든 서버는 메시지 및 모니터링, 미터 및 로그가 정상으로 작동됩니다. 고객이이 라우팅 문제로 영향을받는 네트워크에서 연결되는 고객은 연결 시간도 볼 수 있습니다. 우리는 공급자에게 문제를 보고하고 그것의 주위에 우리의 자신의 관리 소통량을 여정입니다.

2. 2026년 10월 6일 오후 3:44 UTCmonitoring

   루팅은 정상으로 돌아갑니다.

3. 2026년 10월 6일 오후 3:48 UTCresolved

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

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

1. 2026년 8월 26일 오후 1:27 UTCinvestigating

   우리는 현재이 문제를 조사하고 있습니다.

2. 2026년 8월 26일 오후 1:28 UTCidentified

   문제는 식별되고 수정이 구현됩니다.

3. 2026년 8월 26일 오후 1:41 UTCmonitoring

   수정이 구현되어 결과를 모니터링하고 있습니다.

4. 2026년 8월 26일 오후 1:57 UTCresolved

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

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

1. 2026년 8월 24일 오후 11:52 UTCmonitoring

   DigitalOcean은 현재 API 및 제어판과 문제가 발생하고 문제가 발생하면서 오류와 높은 지연으로 실행할 수 있습니다

2. 2026년 8월 25일 오후 11:58 UTCresolved

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

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

1. 2026년 7월 23일 오후 3:33 UTCinvestigating

   Azure West US에 배포된 서버 몇 개에 대해 알리는 다양한 경고를 받았습니다. 서버의 25 %에 영향을 미치는이 지역과 관련된 것 같습니다.

2. 2026년 7월 23일 오후 7:50 UTCmonitoring

   Microsoft Azure는 웨스트 미국 지역에 네트워크 문제가있었습니다. 현재 대부분의 서버는 운영 중입니다. 우리는 뒤에 오는 시간 동안 감시를 지킬 것입니다.

3. 2026년 7월 23일 오후 9:48 UTCresolved

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

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

1. 2026년 6월 26일 오전 8:38 UTCinvestigating

   We are currently investigating this issue.

2. 2026년 6월 26일 오전 9:17 UTCidentified

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

3. 2026년 6월 26일 오후 2:22 UTCmonitoring

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

4. 2026년 6월 26일 오후 2:44 UTCresolved

   This incident has been resolved.

5. 2026년 6월 29일 오전 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. 2026년 5월 30일 오후 10: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. 2026년 5월 31일 오전 11:29 UTCresolved

   This incident has been resolved.

1. 2026년 5월 23일 오후 4: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. 2026년 5월 23일 오후 5: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. 2026년 5월 22일 오전 3: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. 2026년 5월 22일 오전 4:08 UTCmonitoring

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

3. 2026년 5월 22일 오전 4:50 UTCresolved

   This incident has been resolved.

4. 2026년 5월 22일 오후 1: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. 2026년 5월 19일 오후 1: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. 2026년 5월 19일 오후 1:36 UTCidentified

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

3. 2026년 5월 19일 오후 1:41 UTCmonitoring

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

4. 2026년 5월 19일 오후 1:50 UTCresolved

   This incident has been resolved.

1. 2026년 5월 5일 오전 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. 2026년 5월 5일 오전 10:41 UTCmonitoring

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

3. 2026년 5월 5일 오전 11:23 UTCmonitoring

   Still seeing slow requests, doing another investigation.

4. 2026년 5월 5일 오전 11:34 UTCmonitoring

   Looks like we're back at full performance now.

5. 2026년 5월 5일 오후 1:23 UTCresolved

   This incident has been resolved.

1. 2026년 5월 3일 오후 7:11 UTCinvestigating

   We are currently investigating this issue.

2. 2026년 5월 3일 오후 7: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. 2026년 5월 4일 오전 1:44 UTCresolved

   This incident has been resolved.

1. 2026년 4월 28일 오전 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. 2026년 4월 28일 오전 10:49 UTCidentified

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

3. 2026년 4월 28일 오전 10:53 UTCmonitoring

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

4. 2026년 4월 28일 오전 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. 2026년 4월 24일 오전 9:36 UTCinvestigating

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

2. 2026년 4월 24일 오전 11:12 UTCresolved

   This incident has been resolved.

1. 2026년 4월 23일 오전 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. 2026년 4월 23일 오전 10:56 UTCresolved

   This incident has been resolved.

1. 2026년 4월 23일 오전 4: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. 2026년 4월 23일 오전 6:53 UTCmonitoring

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

3. 2026년 4월 23일 오전 11:32 UTCresolved

   This incident has been resolved.

4. 2026년 4월 24일 오전 8: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. 2026년 4월 15일 오후 3: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. 2026년 4월 2일 오후 2: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. 2026년 4월 2일 오후 2: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. 2026년 4월 2일 오후 3:07 UTCidentified

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

4. 2026년 4월 2일 오후 3: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.