PubNub Incident History

1. postmortemOct 30 · 17:23 UTC

   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.

Reported by PubNub on their status page.

1. ResolvedOct 26 · 21:46 UTC

   This incident has been resolved. If you feel you were impacted, please contact support@pubnub.com.

Reported by PubNub on their status page.

1. postmortemOct 29 · 21:39 UTC

   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.

Reported by PubNub on their status page.

1. ResolvedOct 26 · 21:55 UTC

   This incident has been resolved, and we will follow up with a postmortem. If you have questions or concerns, please reach out to support@pubnub.com.

Reported by PubNub on their status page.

1. postmortemOct 26 · 21:36 UTC

   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.

Reported by PubNub on their status page.

1. ResolvedOct 22 · 16:35 UTC

   This incident has been resolved. If you feel you were impacted, please contact support@pubnub.com.

Reported by PubNub on their status page.

1. postmortemOct 26 · 21:30 UTC

   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. 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.

Reported by PubNub on their status page.

1. ResolvedOct 22 · 02:47 UTC

   We have had no additional reports related to this issue. If you feel you were impacted, please contact support@pubnub.com. A post-mortem will follow.

Reported by PubNub on their status page.

1. postmortemOct 14 · 17:19 UTC

   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.

Reported by PubNub on their status page.