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.

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

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.

The unscheduled maintenance has finished and the platform is fully operational again.

We applied a series of updates that speed up failover for our database and cache layers, improve retry handling across the API and SMTP relay services, and patch the Kubernetes runtime to include the latest security patches and bug fixes.

As a result, the system now recovers from transient issues more quickly and provides a smoother experience for users.

Thank you for your patience and apologies for any inconvenience caused.

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.

The issue has been resolved and all queued emails are sent out.

We sincerely apologies for the inconvenience and will provide a write-up later today.

If you still notice any issues, do not hesitate to contact us.

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

All queued emails have been processed and delivery is back to normal.

We are implementing additional failover mechanisms to mitigate future upstream incidents.

If you experience further issues, please contact support.

During our scheduled maintenance window, we experienced a temporary disruption in service availability. This resulted in database connectivity errors for some of our services.

The disruption was caused by an unexpected behavior change in our database connection pooling layer after a routine component update. The update enforced stricter SSL parameter negotiation than previous versions, which prevented the pooler from establishing secure connections to the backend database.

This was an undocumented upstream edge case and was not caught by our pre-deployment testing.

We detected the issue quickly and reverted the update, after which connectivity was restored. We are tracking the upstream fix and will roll it out only after additional validation.

Impact was limited because maintenance is performed during low-traffic windows, but we apologize for the disruption.

To reduce the likelihood of similar incidents, we are:

• Further aligning staging and production configuration for database connectivity and SSL behavior.

• Strengthening our maintenance readiness checks, including reviewing relevant upstream issues and release notes before changes are applied.

As always, we are committed to improving reliability and continuously refining our processes.

All emails have been sent out successfully again and are no longer seeing any issues. We are going to work on improving resilience against upstream provider issues related to object storage and will share updates on this in the future.

We have not seen any new issues and are closing this incident.