Update (15 October, 18:54 UTC): After further investigation we have narrowed the scope of this incident. Only the Sending API and SMTP Relay were affected, as intermittent errors rather than an outage, so we have changed their status to Degraded performance. We have also removed the other components we originally listed, because they were not affected. The details below reflect what we found.

---

Between 18:26 and 18:30 UTC (20:26–20:30 CEST) on 15 October, some requests to the sending API and SMTP returned errors.

What happened

One connection in the pool that links our application to the primary database ended up in a read-only state. Requests that were given this connection could not write to the database, so the send requests among them failed with a server error. All other connections kept working normally, so only part of the traffic was affected during this window.

Impact

• About 170 send requests (via /v1/send and SMTP) were rejected with a temporary error. Messages from rejected requests were not accepted and not sent. Clients that retry on temporary errors will have resent them automatically. Batch sends were not affected.

• A small number of webhook deliveries and status updates were delayed.

• Tracking, custom domains, inbound email, the Team API and the dashboard were not affected.

• No data was lost or corrupted.

Resolution

We found the affected connection and removed it from the pool. Error rates were back to normal at 18:30 UTC. We are adding a safeguard so that connections in this state are detected and replaced automatically.

If you saw failed sends during this window and your integration does not retry automatically, please resend those messages.

Our sincere apologies for the inconvenience.

This incident has been resolved. Webhooks are operating normally again.

The backlog has also been fully processed and no more delays have been noticed.

We are already actively engaged in working on a solution to prevent these delays in the future with the same cause.

Apologies for the inconvenience this may have caused.

This incident has been resolved. The API and SMTP relay are operating normally again.

The incident affected a small percentage of requests between 7:56 PM CEST and 8:07 PM CEST. No messages have been lost that have been accepted.

We are reviewing the incident and will take any appropriate follow-up measures.

The affected services are operating normally, and we have completed the emergency maintenance. Message intake stopped during two short periods: 18:51–18:57 and 19:02–19:04 CEST. Some tracking requests failed, and webhook delivery was delayed during those periods. During the later emergency maintenance, some Sending API requests returned errors until about 20:04 CEST.

We have monitored the services after the maintenance and are marking this incident resolved. We are sorry for the disruption.

We will publish a public write-up after we confirm the full customer impact, cause, and follow-up actions.

This incident has been resolved. SMTP relay and API are operating normally again.

We have deployed further mitigation measures to prevent this incident from occurring again and are keeping a close eye.

Apologies for the inconvenience this has caused.

We have fully removed the affected IP address from active sending and traffic has been rerouted across our remaining broadcast infrastructure. Email delivery is operating normally again.

The affected IP will remain out of service while we continue working with Microsoft on the block. As this no longer impacts active sending, we are marking this incident as resolved.

Transactional routes and other broadcast IPs remain unaffected.

The cloud provider outage has been resolved, and inbound emails and attachments can now be retrieved normally. We have not observed any further timeouts.

The database maintenance has been completed successfully.

Latency has returned to normal, and all services are operating normally. No further impact is expected.