Is PubNub down?

Users may be experiencing elevated errors with History readers in the Frankfurt point-of-presence. We are working on remediation and will update this as we make progress. If you believe you are affected and would like to discuss, please reach out to [email protected]

A fix has been implemented and we are monitoring the results. If you feel you have been impacted by this, please reach out to [email protected].

This incident has been resolved. If you feel you were impacted, please contact [email protected].

### Problem Description, Impact, and Resolution  On October 26, 2026, from approximately 20:56 to 21:12 UTC, users accessing History APIs in Frankfurt may have experienced elevated error rates and latency. A sudden surge in history read requests exceeded the available capacity of the infrastructure supporting these APIs, temporarily outpacing the autoscaling configuration for that service. Service returned to normal at approximately 21:12 UTC. Following continued monitoring, the incident was declared resolved at 21:46 UTC. ### Mitigation Steps and Recommended Future Preventative Measures  We increased capacity to address the immediate issue. To prevent a similar issue from occurring in the future, we are reviewing the autoscaling configuration of the service so it can better respond to similar traffic surges.

Users may be experiencing elevated error and latency rates with the Presence API. We are working on remediation and will update this as we make progress. If you believe you are affected and would like to discuss, please reach out to [email protected]

A fix for this issue has been implemented and we are monitoring the results. If you feel you have been impacted by this, please reach out to [email protected].

We are continuing to monitor for any further issues.

This incident has been resolved, and we will follow up with a postmortem. If you have questions or concerns, please reach out to [email protected].

### Problem Description, Impact, and Resolution  At approximately 20:40 UTC on October 26, 2026, we observed elevated error rates and latency with the Presence API across multiple regions globally. A software update to the Presence service triggered resource issues that reduced the number of servers available to handle requests. Our team identified the deployment as the source of the errors and initiated a rollback to the previous version.  Error rates returned to normal at approximately 21:07 UTC on October 26, 2026. We continued monitoring as latency improved, returning fully to normal at approximately 21:46 UTC. The incident was declared resolved at 21:55 UTC. ### Mitigation Steps and Recommended Future Preventative Measures  To prevent a similar issue from occurring in the future, we have temporarily paused Presence code deployments while we investigate the update’s resource usage. Before releasing the update again, we will address the identified issues and test resource consumption and service stability, with extra attention to the conditions that we experienced in this scenario.

Users may be experiencing elevated error and latency rates from our Frankfurt and Bombay points-of-presence. We are working on remediation and will update this as we make progress. If you are affected, reach out to [email protected].

The issue has been identified and a fix is being implemented.

A fix has been implemented and we are monitoring the results. If you were impacted by this issue, or feel you are still being impacted, please reach out to [email protected].

This incident has been resolved. If you feel you were impacted, please contact [email protected].

### **Problem Description, Impact, and Resolution** On October 22, from approximately 14:45 to 16:13 UTC, users of our Frankfurt \(FRA\) and Mumbai \(BOM\) points of presence may have seen elevated error rates and latency on Presence API calls. Other PubNub services were not affected. The issue began during a software update to the Presence service in Frankfurt. The new version was not compatible with the previous version while both were running at the same time. That caused Presence servers in the region to restart repeatedly, and requests that could not reach a healthy server returned errors. Our team identified the update as the cause and rolled it back. Service returned to normal at approximately 16:13 UTC. ### **Mitigation Steps and Recommended Future Preventative Measures** We are fixing the incompatibility before this update is released again. We are also adding tests that run old and new versions side by side before every Presence release, rolling out updates one availability zone at a time, and improving our rollback procedure so it does not run incompatible versions together.

An error in updating security certificates may be causing some clients to experience connection issue. We are investigating and will update as we find out more.

We are continuing to investigate this issue.

We have identified the issue and are well into remediation. Please reach out to [email protected] if you are experiencing issues.

We have completed remediation for this issue. Impact was minor: only one end user reported an issue, but we are monitoring for additional impact. Please reach out to [email protected] if you have a related issue to report.

We have had no additional reports related to this issue. If you feel you were impacted, please contact [email protected]. A post-mortem will follow.

### **Problem Description, Impact, and Resolution** From 19:26 UTC on October 21 until approximately 02:04 UTC on October 22, some PubNub endpoints served TLS certificates that our certificate authority had revoked. Clients that check certificate revocation could have failed to connect to the affected endpoints during that window. Our certificate authority found that about 400,000 certificates it had issued contained policy information that did not match its published certificate policy. The certificates were not compromised, but industry rules require such certificates to be revoked and replaced. PubNub's certificates for \*.pubnub.com, \*.pubnub.net, \*.pndsn.com and \*.pubnubapi.com were among them and were revoked on October 21. Our replacement certificates were not deployed to all of our endpoints until after the revocation took effect. Clients that do not check certificate revocation were not affected, nor were connections to the default SDK origin [ps.pndsn.com](http://ps.pndsn.com). We were alerted by an end user of one of our customers. We deployed the replacement certificates to all regions, completing at approximately 02:04 UTC on October 22. Hostnames and the certificate expiry date \(January 7, 2027\) are unchanged. ### **Mitigation Steps and Recommended Future Preventative Measures** We are adding monitoring that alerts our operations team if any certificate we serve is revoked. We are also changing our certificate replacement process so that replacements are deployed to production promptly once issued, and so that certificate updates reach all regions faster.

Starting at 17:32 UTC on October 9, 2026 we observed elevated 5XX error rates and latency on the Subscribe endpoint globally. The issue was resolved by 18:18 UTC and services have returned to normal levels. A limited number of customers may have been affected. A root cause analysis will be published in the coming days. We sincerely apologize for any impact this may have caused. If you feel you were affected and wish to discuss, please email [email protected].

### **Problem Description, Impact, and Resolution**  On October 9, 2026, between 17:30 and 18:20 UTC, we observed elevated HTTP 5xx errors affecting the Subscribe endpoint for a subset of customers. Some subscribe requests may have failed, and a subset of messages may have been delayed or not delivered in real time. No messages were lost, and customers with Message Persistence enabled could retrieve affected messages from History. The incident was caused by an unexpected increase in traffic from a high-volume load test against a development keyset that did not have the expected limits set. The resulting load temporarily exhausted memory in some shared infrastructure, which caused the issue. We stabilized the affected infrastructure by applying a rate limit to the keyset generating the excess load. Service returned to normal by 18:20 UTC. ‌ ### **Mitigation Steps and Recommended Future Preventative Measures**  We applied a temporary publish rate limit to contain the unexpected traffic and restore service while preserving the affected keyset’s availability. To help prevent similar incidents, PubNub is adding additional checks to ensure that safeguards are correctly in place to detect and automatically limit unusually heavy load before it can affect other traffic sharing the same infrastructure. We are also updating operational procedures for subscriber memory and autoscaling changes to ensure that capacity adjustments remain effective during incident mitigation.