Loops: Transactional email, webhooks, SMTP interruptions
AWS us-east-1 outage, Oct 20, 2025 · 141 vendors, 181 incidents
Loops’s incident blames AWS as the cause. (hop 1, posted +1 h 20 min vs AWS’s own post)
“…ansactional email, webhooks, SMTP interruptions 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 seriou…”
Swipe sideways to see the whole diagram.
Mermaid source
flowchart LR
root["AWS us-east-1<br/>posted 07:11 UTC"]:::root
before["Posted before AWS did<br/>5 vendors, 4 blamed AWS<br/>Salesforce, Descope, Ashby +2"]:::blames
root --> before
h1["Within an hour<br/>18 vendors, 17 blamed AWS<br/>Asana, Firebolt, Monday.com +15"]:::blames
root --> h1
h4["1 to 4 hours later<br/>30 vendors, 29 blamed AWS<br/>SingleStore, Loops, Buildkite +27"]:::blames
root --> h4
later["Later<br/>45 vendors, 44 blamed AWS<br/>RudderStack, Airbyte, Unbounce +42"]:::blames
root --> later
p0["Twilio<br/>posted +15 min"]:::blames
root --> p0
k0["BigCommerce<br/>+2 h 46 min"]:::hop2
p0 -->|"blamed Twilio"| k0
p1["Webflow<br/>posted +4 h 37 min, did not name AWS"]:::timing
root -.-> p1
k1["Rootly<br/>+10 h 23 min"]:::hop2
p1 -->|"blamed Webflow"| k1
p2["Baseten<br/>posted +4 min"]:::blames
root --> p2
k2["Zed<br/>+26 h 20 min"]:::hop2
p2 -->|"blamed Baseten"| k2
me["Loops (this incident)<br/>posted +1 h 20 min"]:::me
h4 --- meFull event: timeline, evidence and all vendors →
Detected automatically from incidents that started together and named the same provider. A link means one vendor’s incident named another, not a confirmed cause.
Affected components: Email Sending - TransactionalTransactional
Timeline of updates
- monitoring
An issue in AWS is causing transactional emails to fail.
- monitoring
We are continuing to monitor for any further issues.
- monitoring
We are continuing to monitor for any further issues.
- resolved
This incident has been resolved.
- postmortem
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.
Changes Rewindex caught on this incident
Archive proof
Rewindex commits each version of an incident it captures to a daily checkpoint, chains it to the day before, and has the checkpoint timestamped by FreeTSA and DigiCert. That proves this record existed by then and has not been changed since, by anyone, Rewindex included.
How the archive is checked, and what it cannot prove.
First version captured 18:53 UTC
In the 2026-10-19 checkpoint, timestamped by FreeTSA and DigiCert on Oct 20, 00:41 UTC. Record hash
b1bbcd2080f24b31…
Impact, status and times are the vendor’s own, as last archived. View on stspg.io (opens in new tab).