Loops Status Page

Mar 2, 2026 · resolved Mar 2

This incident has been resolved.

Feb 10, 2026 · resolved Feb 10

This incident has been resolved.

Jan 24, 2026 · resolved Jan 24

This incident has been resolved.

Nov 18, 2025 · resolved Nov 18

This incident has been resolved.

Oct 20, 2025 · resolved Oct 20

On October 20 2025, Loops was impacted by AWS’s outage in the US-EAST-1 region. We observed a variety of misbehaviors during that time, some more serious than others. Overall, the impact to Loops fell within the wider window provided by AWS \(06:49 UTC to 22:53 UTC\). During the outage, we experienced temporary but notable impact to, * Transactional email sending. * Webhook delivery. * Incoming request routing to our SMTP service. **Transactional email** Between 7:02 UTC and 9:18 UTC, transactional email sending was impacted. During this window the Loops API may have accepted transactional requests but failed to send them. Impacted messages were not resent later as we do not store the raw payloads. Timeline: * 7:02 UTC: We began experiencing elevated error rates related to transactional email sending, manifesting as increasing rates of HTTP 500 responses from AWS APIs. * 9:18 UTC: AWS API error rates subside. Transactional sending returns to normal. **Webhooks** Between 9:30 UTC and 10:31 UTC webhook delivery was impacted due to the inability to provision sufficient EC2 capacity. Timeline: * 9:30 UTC: Error rates between the Loops API and our backend webhooks service rise. * 10:01 UTC: The issue is identified as insufficient capacity for the webhooks service due to EC2 provisioning scarcity. * 10:31 UTC: Error rates subside as we change our autoscaling configurations to accept a wider range of EC2 instance types and sizes. **SMTP availability** Between approximately 19:33 UTC and 21:35 UTC an incorrect DNS entry was returned in the results for the network load balancer \(NLB\) used by our SMTP service. During this window, one of three IP addresses returned by DNS responses were unable to accept connections. Attempts to connect to the incorrect IP address manifested as timeouts. Timeline: * ~19:33 UTC: An IP address returned NLB DNS requests stops accepting connections. DNS requests that select the impacted IP address fail to connect and time out. * ~21:35 UTC: The DNS for the NLB corrects itself and begins returning correct responses.