Is CloudAMQP down?

Last checked 8m ago
Current status
CloudAMQP is up

No incidents right now.

Official status page: https://status.cloudamqp.com · Polled every 5 minutes · 37 components tracked

CloudAMQP is operational right now. Last checked 8m ago; the most recent incident resolved 13d ago.

Real-time CloudAMQP status, recent outages, and incident history — pulled directly from CloudAMQP's official status page at https://status.cloudamqp.com every 5 minutes. Pingoru tracks 37 CloudAMQP services and has captured 16 incidents in the last 90 days (99.58% uptime). Get email, Slack, Discord, or webhook alerts the moment CloudAMQP reports a new incident — free for 5 monitors, no credit card.

Users who monitor CloudAMQP also follow these DevOps services: GitHub Confluence Circle CI OpsGenie JFrog Papertrail Airbrake Splunk OnCall Datadog EU RubyGems View all 6,000+ providers
CloudAMQP uptime 99.58% uptime · past 90 days
Mon Wed Fri
MarAprMayJun
Less More

Recent outages & incidents

Past 90 days
  1. Resolved 13h 4m
    Started May 30, 2026, 10:25 PM UTC · Resolved May 31, 2026, 11:29 AM UTC
    Timeline · 2 updates
    • monitoring · May 30, 2026, 10:25 PM UTC

      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.

    • resolved · May 31, 2026, 11:29 AM UTC

      This incident has been resolved.

    Latest: This incident has been resolved.

  2. Resolved 1h 1m
    Started May 23, 2026, 04:21 PM UTC · Resolved May 23, 2026, 05:23 PM UTC
    Microsoft Azure
    Timeline · 2 updates
    • investigating · May 23, 2026, 04:21 PM UTC

      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.

    • resolved · May 23, 2026, 05:23 PM UTC

      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.

    Latest: 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 nu…

  3. Resolved 1h 33m
    Started May 22, 2026, 03:16 AM UTC · Resolved May 22, 2026, 04:50 AM UTC
    Metrics
    Timeline · 4 updates
    • investigating · May 22, 2026, 03:16 AM UTC

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

    • monitoring · May 22, 2026, 04:08 AM UTC

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

    • resolved · May 22, 2026, 04:50 AM UTC

      This incident has been resolved.

    • postmortem · May 22, 2026, 01:52 PM UTC

      # 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.

    Latest: # 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, Datad…

  4. Resolved 28m
    Started May 19, 2026, 01:21 PM UTC · Resolved May 19, 2026, 01:50 PM UTC
    Backend
    Timeline · 4 updates
    • investigating · May 19, 2026, 01:21 PM UTC

      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.

    • identified · May 19, 2026, 01:36 PM UTC

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

    • monitoring · May 19, 2026, 01:41 PM UTC

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

    • resolved · May 19, 2026, 01:50 PM UTC

      This incident has been resolved.

    Latest: This incident has been resolved.

  5. Resolved 3h
    Started May 05, 2026, 10:23 AM UTC · Resolved May 05, 2026, 01:23 PM UTC
    Backend
    Timeline · 5 updates
    • investigating · May 05, 2026, 10:23 AM UTC

      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.

    • monitoring · May 05, 2026, 10:41 AM UTC

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

    • monitoring · May 05, 2026, 11:23 AM UTC

      Still seeing slow requests, doing another investigation.

    • monitoring · May 05, 2026, 11:34 AM UTC

      Looks like we're back at full performance now.

    • resolved · May 05, 2026, 01:23 PM UTC

      This incident has been resolved.

    Latest: This incident has been resolved.

See the full CloudAMQP outage history

9 more incidents in the last 90 days, plus the full multi-year archive of per-service events and update timelines.

Browse CloudAMQP outage history →

Or sign up free to get alerts when CloudAMQP breaks · 10 free monitors · No credit card

Outage history

Past 90 days · 14 incidents View full outage history →