Lettermint Outage History

Started Oct 15, 2026, 06:26 PM UTC· resolved Oct 15, 2026, 06:30 PM UTC

1. investigating Oct 15, 2026, 06:29 PM UTC

   We are investigating intermittent server errors affecting the platform. We will keep you posted once we know more.

2. resolved Oct 15, 2026, 06:36 PM UTC

   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.

Read the full incident report →

Started Oct 11, 2026, 10:18 AM UTC· resolved Oct 11, 2026, 11:32 AM UTC

1. identified Oct 11, 2026, 10:18 AM UTC

   We have identified the cause of delayed webhook delivery and are working on a fix. Webhook events are currently reaching your endpoints later than usual. No events are lost, they will be delivered once processing catches up. Sending emails through the API and SMTP is not affected, and incoming emails on inbound routes are processed normally.

2. resolved Oct 11, 2026, 11:32 AM UTC

   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.

Read the full incident report →

Started Oct 01, 2026, 05:56 PM UTC· resolved Oct 01, 2026, 06:07 PM UTC

1. monitoring Oct 01, 2026, 06:09 PM UTC

   We have identified the cause of intermittent 500 errors affecting the SMTP relay and APIs and are working on a fix. A small percentage of requests and SMTP sessions were impacted by this. The issue is caused by a corrupted API pod which has now been disabled to mitigate the issue. There should be no more impact as of 8:07 PM CEST.

2. resolved Oct 01, 2026, 06:18 PM UTC

   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.

Read the full incident report →

Started Sep 23, 2026, 04:51 PM UTC· resolved Sep 23, 2026, 06:05 PM UTC

1. investigating Sep 23, 2026, 04:54 PM UTC

   We are investigating service unavailable errors affecting multiple services. Our apologies for the inconvenience. We will share an update once we have more information.

2. identified Sep 23, 2026, 05:06 PM UTC

   We have identified an issue in the infrastructure that supports message processing. We are working to resolve it and will share another update when we have verified the result.

3. identified Sep 23, 2026, 05:33 PM UTC

   We are performing emergency maintenance to increase capacity. Brief service interruptions may occur during this work. We will provide another update when the maintenance is complete and service is stable.

4. monitoring Sep 23, 2026, 06:23 PM UTC

   Email submissions and message processing have resumed. We confirmed two short interruptions: 18:51–18:57 and 19:02–19:04 CEST. Some tracking requests failed and webhook delivery was delayed during those periods. Later, some Sending API requests returned errors; the last such error we observed was around 20:04 CEST. We are monitoring sending and processing, and we are still checking incoming mail, before we resolve this incident.

5. resolved Sep 23, 2026, 08:01 PM UTC

   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.

Read the full incident report →

Started Sep 01, 2026, 04:01 AM UTC· resolved Sep 01, 2026, 07:02 AM UTC

1. investigating Sep 01, 2026, 04:01 AM UTC

   We are investigating failing requests and retries affecting SMTP relay.

2. resolved Sep 01, 2026, 04:06 AM UTC

   On September 1, between 04:01 and 04:06 UTC, one of our API instances returned errors for a small number of requests. Some customers sending email through our API or SMTP service might have seen a submission or authentication error. Other instances remained healthy, and most requests continued normally. No email already accepted by Lettermint was lost. Failed requests stopped before we accepted or created the message, so clients could retry them after service recovery. A small number of email-open events might not have been recorded. No stored customer data was changed or exposed. The cause was a defect in the PHP JIT. We already had a safeguard for this issue, but it did not cover this additional code path. We expanded the safeguard and removed the affected date calculation from the application startup process. This lets us keep the performance optimisation active for the rest of the application. We will also install the permanent PHP fix when it becomes available in our production runtime which at the time of writing is not the case. We continue to monitor the service. We are sorry for the disruption.

3. investigating Sep 01, 2026, 07:05 AM UTC

   We have been made aware of this issue reoccurring again and are currently investigating. The incident has already been mitigated by killing the affected pod. We will share an update once we know more.

4. resolved Sep 01, 2026, 07:40 AM UTC

   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.

Read the full incident report →

Started Aug 11, 2026, 08:03 AM UTC· resolved Aug 11, 2026, 09:19 AM UTC

1. investigating Aug 11, 2026, 08:03 AM UTC

   We’ve identified that one of our outbound broadcast IP addresses have been blocklisted, affecting email delivery for some customers. The team is currently investigating the cause and working on delisting the IP. In the meantime, the IP address has been suspended and will not be used until the issue is resolved. This does not affect other IPs in the pool nor transactional routes. If you have seen a hard bounce because of this, you can safely reactivate the recipient from your suppression management.

2. identified Aug 11, 2026, 08:24 AM UTC

   We have identified the source of the listing and are actively remediating the issue. We will keep monitoring the situation. Our sincere apologies for the inconvenience.

3. resolved Aug 12, 2026, 08:13 AM UTC

   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.

Read the full incident report →

Started Jul 23, 2026, 11:19 AM UTC· resolved Jul 23, 2026, 02:23 PM UTC

1. monitoring Jul 23, 2026, 11:19 AM UTC

   We are seeing elevated timeouts when accessing object storage due to an ongoing cloud provider outage. Our failover systems are operating as expected, but some requests may still time out. We are monitoring the situation closely.

2. resolved Jul 23, 2026, 02:23 PM UTC

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

Read the full incident report →

Started Jul 15, 2026, 03:00 PM UTC· resolved Jul 15, 2026, 03:01 PM UTC

1. investigating Jul 15, 2026, 03:00 PM UTC

   We are investigating an increase in 503 Service Unavailable responses.

2. monitoring Jul 15, 2026, 03:01 PM UTC

   We experienced a brief period of API unavailability, during which some requests returned 503 Service Unavailable. Multiple API instances temporarily became unresponsive at the same time, leaving insufficient capacity to serve requests. Service has been restored and remains stable. We are monitoring closely and investigating what caused the instances to become unresponsive.

3. resolved Jul 15, 2026, 03:15 PM UTC

   API availability has been fully restored and the platform has remained stable. We reverted a health-check configuration that reacted too aggressively to a brief traffic spike, causing healthy instances to be temporarily removed from service. We have confirmed normal operation and are reviewing additional safeguards to prevent a recurrence.

Read the full incident report →

Started Jun 27, 2026, 05:05 PM UTC· resolved Jun 27, 2026, 05:31 PM UTC

1. investigating Jun 27, 2026, 05:39 PM UTC

   We are seeing increased error rates on the Lettermint dashboard and our Team API. Requests to the Team API and actions in the dashboard may fail or respond slowly while we look into this. Email delivery is not affected. Transactional and broadcast messages are still being sent and processed as normal. Our team is investigating the cause and we will post an update shortly.

2. monitoring Jun 27, 2026, 06:01 PM UTC

   We are no longer seeing elevated error rates on the Team API or dashboard and functionality appears to have returned to normal. We are continuing to monitor the situation closely to ensure stability, but no new errors have been observed since mitigation was applied.

3. resolved Jun 27, 2026, 06:05 PM UTC

   This incident has been resolved. We applied a fix and have confirmed that the dashboard and Team API are working normally, with no further errors.

Read the full incident report →

Started Jun 26, 2026, 08:56 PM UTC· resolved Jun 26, 2026, 09:01 PM UTC

1. investigating Jun 26, 2026, 08:56 PM UTC

   We are investigating an increase in 500 errors.

2. resolved Jun 26, 2026, 09:01 PM UTC

   We resolved the API token authentication issue at 23:01 CEST by rolling back the change that introduced the failure. Between approximately 22:56 and 23:01 CEST, a subset of API requests authenticated with tokens may have returned 500 errors when they required a fresh authentication lookup. Requests using already-cached token authentication continued to work. The issue was caused by a database migration/deployment sequencing problem. The change introduced a new table for token authentication data and was designed to be backwards compatible: if no token data existed in the new table yet, authentication would fall back to the existing data source. This fallback behavior worked as expected in development and staging. However, our staging environment did not reproduce the production migration timing. In production, the migration ran significantly longer because of the larger dataset and remained inside a transaction. Until that transaction committed, the newly-created table was not yet visible to the application. As a result, fresh token authentication lookups could fail before the intended fallback path was reached. In other words, we accounted for missing data in the new table, but not for the table itself being temporarily unavailable during a long-running transactional migration. This was our mistake. We tested the change and specifically designed it to avoid breaking existing authentication data, but our deployment safeguards did not adequately cover this failure mode. Given the recent increase in production incidents, we are treating this as a high-priority reliability issue. We are pausing this rollout path and tightening our deployment process before reintroducing the change. In particular, we will separate schema changes from longer-running migration work, add explicit preflight checks for required database objects before enabling dependent code paths, and apply stricter rollout gates to authentication-related changes. All affected services are currently operating normally.

Read the full incident report →

Started Jun 23, 2026, 08:39 AM UTC· resolved Jun 23, 2026, 04:24 PM UTC

1. identified Jun 23, 2026, 08:39 AM UTC

   We are actively mitigating this issue. You might see deferrals in your webhooks or UI instead of delayed processing. Please note emails are still being retried. This is caused by an increase in volume due to the ongoing incident with Spamhaus listing, which is being resolved and the delisting is being propagated. This issue does not impact Microsoft 365 (Outlook 365) addresses nor other providers. Broadcast is also not affected by the issue. Our sincere apologies for the inconvenience.

2. monitoring Jun 23, 2026, 09:30 AM UTC

   We are seeing improvements and emails are being delivered. We will keep monitoring the situation closely.

3. resolved Jun 23, 2026, 04:24 PM UTC

   We are not seeing anymore deferrals related to ratelimit for these IPs and will mark it as resolved. Apologies for the inconvenience this has caused.

Read the full incident report →

Started Jun 23, 2026, 06:01 AM UTC· resolved Jun 23, 2026, 04:24 PM UTC

1. identified Jun 23, 2026, 06:01 AM UTC

   We’ve identified that three of our outbound transactional IP addresses have been blocklisted, affecting email delivery for some customers. The team is currently investigating the cause and working on delisting the IP. In the meantime, the IP address has been suspended and will not be used until the issue is resolved. This does not affect other IPs in the pool nor broadcast routes. If you have seen a hard bounce because of this, you can safely reactivate the recipient from your suppression management.

2. identified Jun 23, 2026, 08:41 AM UTC

   We are still actively working on this issue. An update from Spamhaus was received ~20 minutes ago and delisting is being propagated worldwide. We will keep monitoring the situation. Our sincere apologies for the inconvenience.

3. identified Jun 23, 2026, 10:47 AM UTC

   We are still actively working on this issue and are awaiting an update from Spamhaus. We will keep monitoring the situation. Our sincere apologies for the inconvenience.

4. identified Jun 23, 2026, 01:38 PM UTC

   We are still actively working on this issue and are awaiting an update from Spamhaus. We will keep monitoring the situation. Our sincere apologies for the inconvenience.

5. monitoring Jun 23, 2026, 03:14 PM UTC

   We’ve been in contact with Spamhaus and the delisting process has now been successfully applied. The delisting has been put into effect, but mail providers that rely on Spamhaus may take some time to refresh and propagate these changes within their own systems and internal caches. We are currently monitoring the situation closely while these updates continue to propagate. Once we determine that delivery has stabilized and it is safe to proceed, we will begin retrying affected emails that were not yet successfully delivered and provide further updates as needed.

6. resolved Jun 23, 2026, 04:24 PM UTC

   We are not seeing anymore bounces related to the Spamhaus listing and are working on resending all impacted messages. Due to the length and impact of this incident we will share a post-mortem on this incident. Apologies for the inconvenience this has caused.

Read the full incident report →

Started Jun 22, 2026, 12:32 PM UTC· resolved Jun 22, 2026, 01:07 PM UTC

1. monitoring Jun 22, 2026, 12:32 PM UTC

   We’ve identified that one of our outbound transactional IP addresses has been blocklisted, affecting email delivery for some customers. The team is currently investigating the cause and working on delisting the IP. In the meantime, the IP address has been suspended and will not be used until the issue is resolved. This does not affect other IPs in the pool nor broadcast routes. If you have seen a hard bounce because of this you can safely reactivate the recipient from your suppression management. As of 11.44 UTC, the listing has been removed and we are monitoring the situation.

2. resolved Jun 22, 2026, 01:07 PM UTC

   We have not seen any new bounces due to the listing and are actively looking into resending all bounced messages. Recipients that bounced due to the Spamhaus listing should not be suppressed. If it still did so, feel free to remove these from the suppression list. Our sincere apologies for the inconvenience.

Read the full incident report →

Started Jun 19, 2026, 12:48 PM UTC· resolved Jun 20, 2026, 08:41 AM UTC

1. identified Jun 19, 2026, 12:48 PM UTC

   We have identified an issue with messages being rate limited against Outlook OLC and are actively remediating. Emails will be delivered after retries and does not impact other providers nor Microsoft 365 (Office 365) tenants.

2. identified Jun 19, 2026, 01:55 PM UTC

   Our automated traffic shaping has partially mitigated the issue but are awaiting further mitigation from Microsoft. Emails to Outltook OLC are still delayed and might show as Processed for an extended period of time in the UI. This issue does not impact Microsoft 365 (Outlook 365) addresses nor other providers.

3. identified Jun 19, 2026, 04:20 PM UTC

   We are still actively remediating the issue. Our automated traffic shaping has partially mitigated the issue but are awaiting further mitigation from Microsoft. Emails to Outlook OLC are still delayed and might show as Processed for an extended period of time in the UI. This issue does not impact Microsoft 365 (Outlook 365) addresses nor other providers.

4. identified Jun 19, 2026, 07:26 PM UTC

   We are still actively remediating the issue. Our automated traffic shaping has partially mitigated the issue but are awaiting further mitigation from Microsoft. Emails to Outlook OLC are still delayed and might show as Processed for an extended period of time in the UI. This issue does not impact Microsoft 365 (Outlook 365) addresses nor other providers. Broadcast is also not affected by the issue. Our sincere apologies for the inconvenience.

5. identified Jun 19, 2026, 09:49 PM UTC

   We are still actively remediating the issue and have changed our mitigation. You might see deferrals in your webhooks or UI instead of delayed processing. Please note emails are still being retried. To make sure emails will be delivered, we have increased our maximum wait time to 24 hours instead of 12 hours and are actively monitoring the situation in case further extension is needed. We hope to hear back from Microsoft's Sender Support as soon as possible. This issue does not impact Microsoft 365 (Outlook 365) addresses nor other providers. Broadcast is also not affected by the issue. Our sincere apologies for the inconvenience.

6. identified Jun 20, 2026, 04:59 AM UTC

   We are still actively remediating the issue and have changed our mitigation. You might see deferrals in your webhooks or UI instead of delayed processing. Please note emails are still being retried. To make sure emails will be delivered, we have increased our maximum wait time to 24 hours instead of 12 hours and are actively monitoring the situation in case further extension is needed. We hope to hear back from Microsoft's Sender Support as soon as possible. This issue does not impact Microsoft 365 (Outlook 365) addresses nor other providers. Broadcast is also not affected by the issue. Our sincere apologies for the inconvenience.

7. monitoring Jun 20, 2026, 08:41 AM UTC

   We are seeing improvements and emails are being delivered. We will keep monitoring the situation closely.

8. resolved Jun 20, 2026, 10:42 AM UTC

   We are not seeing any more deferrals with Outlook OLC and mark this incident as resolved. During the incident we have adjusted our traffic shaping to improve mitigation for incidents like this in the future. We have since seen improvements. Our sincere apologies for the inconvenience and the delay in delivery of emails sent to consumer Outlook addresses.

Read the full incident report →

Started Jun 17, 2026, 05:48 PM UTC· resolved Jun 17, 2026, 06:09 PM UTC

1. investigating Jun 17, 2026, 05:00 PM UTC

   We are currently investigating reports of email submitted via the SMTP relay not being processed.

2. identified Jun 17, 2026, 05:52 PM UTC

   We have identified the issue and our team is working on a fix. We'll keep you posted. Apologies for the inconvenience.

3. monitoring Jun 17, 2026, 06:06 PM UTC

   A fix is being deployed and we'll be monitoring the situation.

4. monitoring Jun 17, 2026, 06:09 PM UTC

   We are seeing improvements and services are back to normal. In the meantime, we will keep monitoring the situation closely and apologies for the inconvenience this has caused. A public post-mortem will also be shared.

5. resolved Jun 17, 2026, 08:18 PM UTC

   We have continued monitoring and have not observed any further recurrence of this issue. The incident is now resolved. We have completed a post-mortem and will publish it shortly with more detail on the impact, root cause, and follow-up actions.

Read the full incident report →

Started May 29, 2026, 10:59 AM UTC· resolved May 29, 2026, 12:00 PM UTC

1. investigating May 29, 2026, 10:59 AM UTC

   We are currently investigating a sudden increase in queue times for emails. Emails are delayed for ~2 minutes on average. We will keep you posted.

2. identified May 29, 2026, 11:09 AM UTC

   We have identified the issue causing a delay in processing of emails and are working on a fix. Currently emails are in queue for an average of ~22 seconds, higher than the usual average of a couple milliseconds. We will keep you posted once a fix has been implemented.

3. monitoring May 29, 2026, 12:00 PM UTC

   A fix has been implemented and we're monitoring the situation. Queues are being processed quickly again and the time-to-inbox dropped to sub-10 seconds as expected. Apologies for the inconvenience this caused.

4. resolved May 29, 2026, 01:20 PM UTC

   We have not seen any regressions related to emails being queued for longer than expected. Therefore we're marking this incident as resolved. If you still notice any issues, do reach out to support.

Read the full incident report →

Started Apr 07, 2026, 06:43 PM UTC· resolved Apr 07, 2026, 07:52 PM UTC

1. investigating Apr 07, 2026, 06:43 PM UTC

   We are noticing degraded performance with sending larger attachment to our SMTP relay and are currently investigating the issue.

2. monitoring Apr 07, 2026, 07:52 PM UTC

   Fix has been deployed for the intermittent connection errors affecting SMTP submissions with larger attachments. We are now observing traffic to confirm the issue is fully resolved. No action is required from customers.

3. resolved Apr 07, 2026, 08:31 PM UTC

   We are no longer seeing any connection issues. A post-mortem will be shared as soon as possible. Our findings have been shared with the developer of the package and will cooperate to fix the issue for the ecosystem.

Read the full incident report →

Started Mar 27, 2026, 06:17 PM UTC· resolved Mar 27, 2026, 06:30 PM UTC

1. identified Mar 27, 2026, 06:24 PM UTC

   We have identified the issue with our email sending API and are working on a fix. SMTP is not affected. We will provide updates as soon as we have more information.

2. monitoring Mar 27, 2026, 06:32 PM UTC

   We have deployed a fix for the issues with our email sending API. We are no longer seeing errors and will continue to monitor.

3. resolved Mar 27, 2026, 06:53 PM UTC

   This incident is resolved. Our email sending API is fully operational and we are no longer seeing any errors or alerts.

Read the full incident report →

Started Mar 25, 2026, 07:36 AM UTC· resolved Mar 25, 2026, 08:28 AM UTC

1. investigating Mar 25, 2026, 07:36 AM UTC

   We are observing an increased amount of softbounces due to issues related to networking and are currently investigating. Only a small percentage of traffic is impacted and will be retried in minutes.

2. monitoring Mar 25, 2026, 08:28 AM UTC

   The root cause has been identified and a fix has been implemented. We will keep monitoring the results, all emails are now being forced to retry immediately.

3. resolved Mar 25, 2026, 08:56 AM UTC

   We are no longer seeing any issues and are marking this incident as resolved. We apologise for the inconvenience this may have caused.

Read the full incident report →

Started Mar 05, 2026, 09:26 AM UTC· resolved Mar 05, 2026, 10:22 AM UTC

1. investigating Mar 05, 2026, 09:26 AM UTC

   We are investigating possible issues related to accessing Lettermint services. Updates will be shared as soon as we know more.

2. monitoring Mar 05, 2026, 09:40 AM UTC

   We are monitoring the situation following an infrastructure node failure in one of our availability zones. Read database queries experienced degradation for approximately 72 seconds between 09:21–09:23 UTC impacting authentication during email submission and other endpoints. Write operations and cache services were unaffected throughout. All services have fully recovered.

3. identified Mar 05, 2026, 10:07 AM UTC

   We have received an update to the cause of this incident, which is in fact not related to a node hardware failure as previously thought. Our cloud provider has accidentally triggered a rolling replacement of all cluster nodes in our EU-West region. This process is ongoing and may cause intermittent latency spikes or brief errors as workloads migrate and failover between nodes. Impact should be minimal. Our team is in contact with our cloud provider to receive updates on the resolution. We will provide updates as the situation develops.

4. monitoring Mar 05, 2026, 10:22 AM UTC

   Our cloud provider confirmed the roll-out was stopped. We are also no longer observing any more nodes being replaced for the last 30 minutes. All services are healthy again and we will keep monitoring the situation.

5. resolved Mar 05, 2026, 11:11 AM UTC

   No more regressions have been noticed and all services are still healthy. Incident has been resolved. A follow-up from our cloud provider is still expected and we are taking measures to prevent issues like this in the long-term.

Read the full incident report →

Started Feb 17, 2026, 03:24 PM UTC· resolved Feb 17, 2026, 04:26 PM UTC

1. identified Feb 17, 2026, 03:24 PM UTC

   We've identified that two of our outbound broadcast IP addresses have been ratelimited, affecting email delivery for some customers. The team is currently investigating the cause and working on delisting the IPs. In the meantime, the IP addresses has been suspended and will not be used until the issue is resolved. This does not affect other IPs in the pool nor transactional routes. These rate limits cause soft-bounces. We will keep retrying to send the emails.

2. monitoring Feb 17, 2026, 04:26 PM UTC

   We're no longer seeing any bounces, but we'll keep monitoring it.

3. resolved Feb 18, 2026, 01:08 AM UTC

   We are no longer seeing any deferrals related to these IP addresses and emails are sent out accordingly.

Read the full incident report →

Started Feb 13, 2026, 03:20 PM UTC· resolved Feb 13, 2026, 05:27 PM UTC

1. investigating Feb 13, 2026, 03:20 PM UTC

   We've been notified of intermittent delivery failures due to hard bounces to iCloud, affecting email delivery for some customers. The team is currently investigating the cause and working on resolving this issue. If you have seen a hard bounce because of this you can safely reactivate the recipient from your suppression management.

2. resolved Feb 13, 2026, 05:27 PM UTC

   We see improvements and no more bounces related to the block. After further investigation, iCloud was having issues where it was incorrectly rejecting mail with IP block responses while it was not the case. This has been confirmed with others. We will keep monitoring the situation closely.

Read the full incident report →

Started Feb 05, 2026, 11:20 AM UTC· resolved Feb 05, 2026, 11:46 AM UTC

1. identified Feb 05, 2026, 11:20 AM UTC

   At approximately 12:20 PM (CET), we started receiving reports of infrastructure issues affecting our services. This is currently causing database connectivity problems, which may result in failed API requests or delays in email processing. Our team is actively investigating the issue. We will provide updates as soon as more information is available.

2. monitoring Feb 05, 2026, 12:53 PM UTC

   Our services have been restored and we are no longer seeing any issues. We are closely monitoring our infrastructure to ensure everything remains stable. Once this incident is fully resolved, we will publish a post-mortem with a detailed overview of what happened and what steps we are taking to prevent this in the future.

3. resolved Feb 05, 2026, 01:48 PM UTC

   We have confirmed everything is stable again and are working with our upstream provider to work out the final details. As part of our post-incident process we are working on resolving any individual issues that might still have occurred. Do reach out to support if you have any questions. Our sincere apologies for the inconvenience. A post-mortem will be shared as soon as possible.

Read the full incident report →

Started Jan 22, 2026, 11:31 AM UTC· resolved Jan 22, 2026, 11:49 AM UTC

No vendor updates were posted for this incident.

Read the full incident report →

Started Jan 21, 2026, 11:13 AM UTC· resolved Jan 21, 2026, 03:15 PM UTC

No vendor updates were posted for this incident.

Read the full incident report →