All Firebase and Resend connector services are running normally.
Firebase Cloud Messaging integration for mobile and web push delivery.
Source: status.firebase.google.com (Cloud Messaging)
FCM token registration — status from Firebase Cloud Messaging
PushFire engine worker — configure Supabase for delivery metrics
Resend integration for transactional and broadcast email delivery.
Source: resend-status.com (Email Sending)
Source: resend-status.com (General API — domain management)
PushFire engine worker — configure Supabase for delivery metrics
We have resolved the underlying issue and service has been resumed.
The fix for downloading email attachments has been pushed and we are now monitoring the situation.
We are currently investigating issues with downloading attachments where existing download URLs would incorrectly return a 403 response.
We believe the incident was fully mitigated as of 11:40pm.
We are starting to see some recovery.
Mitigation work is currently underway by our engineering team. We do not have an ETA for mitigation at this point. We will provide more information by Thursday, 2026-06-11 03:00 PDT. Customers may observe requests to send messages to FCM taking longer to complete. A small number may experience 5xx errors and should retry with backoff.
We are experiencing an issue with Firebase Cloud Messaging’s send apis in Asia beginning on Wednesday, 2026-06-10 21:50 PDT. Our engineering team continues to investigate the issue. We will provide an update by Wednesday, 2026-06-10 23:45 PDT with current details.
We have resolved the underlying issue and service has been resumed.
The fix has been pushed and we are now monitoring the situation.
We are currently reverting a change that cause quotas to be calculated incorrectly.
We have resolved the underlying issue and service has been resumed.
We are currently investigating increased latency in Resend dashboard. At this time, you may experience delays and errors while trying to access our dashboard.
We have resolved the underlying issue by reverting the unintended breaking change and service has been resumed.
A recent change to how Resend processes inbound emails affected customers who receive emails via server-side forwarding rules, where a mail server automatically redirects an email to a different address without rewriting its headers. When an email is forwarded this way to a Resend inbound address, the to field in the inbound webhook payload began reflecting the original "To" header (e.g. support@yourcompany.com) rather than the address that actually received the delivery (e.g. your Resend inbound address). Direct emails and client-side forwards were not affected.
This incident is resolved. All failed provisioning requests have been reprocessed, and custom tracking domain creation is operating normally.
Issue identified and resolved for new requests. New customers can now create custom tracking domains again. We're replaying the failed provisioning requests from the outage window. This may take some time to fully process.
Since 09:45 UTC on May 5, 2026, new customers are unable to create custom tracking domains. Existing tracking domains and email sending are not affected. We've identified the cause as an upstream infrastructure limit and are working with our provider to resolve it.
We have resolved the underlying issue and service has been resumed.
We are currently investigating increased latency in email sending. At this time, you may experience delays when sending emails via our SMTP service and API.
The pending domain verifications and broadcasts are catching-up quickly. The incident should fully resolve soon.
The underlying issue has been identified and our third-party provider has pushed improvements. We're seeing an improvement in domain verifications and broadcast email throughput. We'll continue to monitor the situation and work on mitigation actions.
We've identified the root cause. We're working with a third-party provider to solve the underlying issue as we work on mitigation actions. In addition to Broadcasts, Domain verification may take longer than usual.
We are currently investigating an increase in latency when sending Broadcasts
We have resolved the underlying issue and service has been resumed.
The fix has been pushed to the General API and we are now monitoring the situation.
A fix has been applied for Email Sending and SMTP, and we are now monitoring the situation. You may still notice errors on our general API endpoints.
We’ve identified the root cause and are working on a fix. We’ll share updates as soon as more information becomes available.
We are currently investigating an issue affecting email sending. At this time, you may encounter 404 errors when sending emails via our SMTP service and API.
We have resolved the underlying issue and service has been resumed.
We are currently investigating increased latency in transactional email sending. At this time, you may experience delays when sending transactional emails via our SMTP service and API.
We have resolved the underlying issue and service has been resumed.
We are currently investigating increased latency in email sending. At this time, you may experience delays when sending emails via our SMTP service and API.
We have resolved the issue causing increased latency in email sending. Emails are being delivered normally.
We have resolved the issue causing increased latency in email sending. All emails should now be delivered without delay.
We have identified the cause of increased latency in email sending. A subset of customers may experience delays when sending emails via our SMTP service and API. We are actively working on a resolution and will provide updates shortly.
We are currently investigating increased latency in email sending. At this time, you may experience delays when sending emails via our SMTP service and API.
We have resolved the underlying issue and service has been resumed.
We're currently investigating errors when contacts try to unsubscribe the audience/segment.
The rollback is complete - service is fully restored.
A recent change is causing 404 errors for clients who send messages to a URL which includes a trailing slash (/v1/projects/my-project/messages:send/ vs /v1/projects/my-project/messages:send). We are in the process of rolling back this change. For clients that are impacted, removing the trailing slash from the send URL will immediately resolve the problem.