https://approjects-vendor-status-watch.static.hf.space/v/pubnub.htmlIncidents from Pubnub's public status page, polled daily.Wed, 16 Sep 2026 12:28:20 +0000https://stspg.io/qctzhs1v265mpubnub:2026-08-25T13:22:48.467ZTue, 25 Aug 2026 13:22:48 +0000### **Problem Description, Impact, and Resolution**  On Tuesday, August 25th, 2026, at 12:10 UTC, our internal monitoring alerted us to an issue where a very small subset of messages within one availability zone of one region \(our US East point of presence\) may not have been immediately delivered to subscribers in that same region. All messages were persisted normally within PubNub Persistence service, **thus no message data was lost.** Traffic to or from any other region or AZ was not affected, and no other PubNub services were affected. No customers reported impact. ### **Root Cause** During planned internal load testing, a group of internal routing servers was removed from service. Due to a configuration flaw, their network addresses were not fully retired and remained cached by ouhttps://stspg.io/wd3pg1rlq378pubnub:2026-08-14T14:29:49.892ZFri, 14 Aug 2026 14:29:49 +0000### **Problem Description, Impact, and Resolution**  At approximately **13:55 UTC on Aug 14, 2026**, we observed elevated publish errors and message replication failures in our publish/subscribe service, which also caused latency in other PubNub services globally. Customers may have experienced increased publish error rates, delayed or missed message delivery, delayed message persistence, and increased latency for Functions and Events & Actions workflows. ‌The root cause of the incident was an unusually large concentration of global publish traffic that was not limited by our throttling layers. That traffic created resource pressure in the publish and replication layers, increased load on storage systems, and caused downstream processing delays in dependent services. We mitigated the isshttps://stspg.io/vj0zdnglj3bnpubnub:2026-06-10T20:14:36.048ZWed, 10 Jun 2026 20:14:36 +0000## Problem Description, Impact, and Resolution  At 19:50 UTC on June 10, 2026, we observed a small fraction of publishes originating from US-EAST-1 failing to replicate to subscribers globally. We removed the degraded publisher pod from service and the issue was resolved at 21:21 UTC on June 10, 2026.  The root cause of the incident was triggered by a single process that fell into a degraded state where it continued receiving inbound traffic and passing health checks, but traffic sent outbound from the process was failing at an abnormally high rate. Our automated health check/recovery system did not auto-detect and replace the degraded process because its health check API reported itself as healthy.  ## Mitigation Steps and Recommended Future Preventative Measures  To prevent a similar https://stspg.io/pb1d9hy71tpppubnub:2026-06-09T14:00:54.000ZTue, 09 Jun 2026 14:00:54 +0000### **Problem Description, Impact, and Resolution**  At approximately **13:20 UTC on June 9, 2026**, we observed elevated publish errors and message replication failures in our publish/subscribe service, which also caused latency in other PubNub services globally. Customers may have experienced increased publish error rates, delayed or missed message delivery, delayed message persistence, and increased latency for Functions and Events & Actions workflows. ‌ The root cause of the incident was an unusually large concentration of global publish traffic that was not limited by our throttling layers. That traffic created resource pressure in the publish and replication layers, increased load on storage systems, and caused downstream processing delays in dependent services. We mitigated the ihttps://stspg.io/3gr2wjq19vphpubnub:2026-03-24T20:21:07.000ZTue, 24 Mar 2026 20:21:07 +0000### **Problem Description, Impact, and Resolution**  On March 24, 2026, at 19:27 UTC, one network shard experienced intermittent connectivity affecting a subset of customers. The affected users may have experienced elevated latency and temporary error responses related to their subscription requests. The instability was caused by an atypical surge in message volume within a shared processing environment that had improperly configured resource limits. This led to high resource utilization and triggered automated system restarts. PubNub Engineering resolved the issue by implementing the proper limits after expanding infrastructure capacity to accommodate the increased load. Service was fully stabilized once the environment was tuned to the new traffic profile. ### **Mitigation Steps and Rehttps://stspg.io/x3ssg0swk2d9pubnub:2026-01-01T00:25:52.918ZThu, 01 Jan 2026 00:25:52 +0000### **Problem Description, Impact, and Resolution**  On January 1, 2026 at 00:00 UTC, we observed elevated latency in our History service across multiple regions. Customers may have experienced delays in message persistence and history availability during this period. The issue was caused by a mismatch in newly created persistence tables. Specifically, required columns for message metadata were missing from the new tables, resulting in failed write operations and backed-up queues. This created downstream pressure on our storage systems, leading to higher latency in history processing. We mitigated the issue by manually applying the correct updates across all affected persistence spaces. After the updates were applied, message processing returned to normal and queue latency cleared. Thihttps://stspg.io/lg4yq11kq4znpubnub:2025-11-20T16:30:00.000ZThu, 20 Nov 2025 16:30:00 +0000**Problem Description, Impact, and Resolution** Starting at 16:46 UTC on Nov. 20, 2025, we noticed a small number of errors with the publish API in the North American and Asia Pacific regions. The system automatically recovered with all functionality fully restored by 16:50 UTC on Nov. 20, 2025.https://stspg.io/gy02hdx72zgspubnub:2025-10-20T13:37:33.401ZMon, 20 Oct 2025 13:37:33 +0000### **Problem Description, Impact, and Resolution**  On October 20th, 2025 at 07:06 UTC, our monitoring systems alerted us to elevated error levels across multiple PubNub services in the IAD region \(US-East\). Some customers may have experienced increased error rates and latency, as well as intermittent issues with Presence service availability across IAD \(US-East\), SJC \(US-West\), and HND \(AP-Northeast\). We quickly determined the issue was caused by a broader infrastructure outage affecting our cloud provider \(AWS\) in the IAD region. We initiated regional failover procedures and re-routed new connections to alternate regions. However, due to undefined steps in some of our failover processes and delays accessing some tools due to the provider issue, existing connections for some https://stspg.io/2812t6gsfk7zpubnub:2025-10-20T07:32:41.000ZMon, 20 Oct 2025 07:32:41 +0000### **Problem Description, Impact, and Resolution**  On October 20th, 2025 at 07:06 UTC, our monitoring systems alerted us to elevated error levels across multiple PubNub services in the IAD region \(US-East\). Some customers may have experienced increased error rates and latency, as well as intermittent issues with Presence service availability across IAD \(US-East\), SJC \(US-West\), and HND \(AP-Northeast\). We quickly determined the issue was caused by a broader infrastructure outage affecting our cloud provider \(AWS\) in the IAD region. We initiated regional failover procedures and re-routed new connections to alternate regions. However, due to undefined steps in some of our failover processes and delays accessing some tools due to the provider issue, existing connections for some https://stspg.io/sp381dwkw3yzpubnub:2025-10-17T06:42:58.000ZFri, 17 Oct 2025 06:42:58 +0000### **Problem Description, Impact, and Resolution**  On October 17, 2025 at 04:51 UTC, some customers may have experienced elevated latency and error rates with the Pub/Sub service in the IAD region \(US-East\). Our engineering teams began immediate investigation and identified a spike in errors related to a recent update to the Pub/Sub service. We began formal incident response and initiated rollback of the service deployment shortly thereafter. The issue was fully resolved by 06:50 UTC, and rollback across all regions was completed by 08:00 UTC. The issue occurred because a misconfiguration in the release caused incorrect behavior in the channel cleanup logic. Additionally, our alerting configuration did not include coverage for the synthetic test failures that would have surfaced thihttps://stspg.io/8gpzcwlbqs91pubnub:2025-10-06T10:13:39.359ZMon, 06 Oct 2025 10:13:39 +0000### **Problem Description, Impact, and Resolution**  At 08:40 UTC on October 6, 2025, we observed elevated error rates in the Events & Actions service in our EU-Central \(FRA\) region, which led to delays in processing publish-triggered events. Some customers may have experienced slower-than-expected execution of their event workflows during this time. We identified a malformed payload that was causing backend consumers to fail when attempting to process the queue. We deployed an updated build with improved parsing logic, which cleared the blockage and restored normal service. The issue was fully resolved by 11:00 UTC on October 6, 2025. This issue occurred because our event processing service did not correctly handle a malformed message format, which caused the processing queue to stalhttps://stspg.io/647gv2199kwmpubnub:2025-09-07T18:45:26.873ZSun, 07 Sep 2025 18:45:26 +0000### **Problem Description, Impact, and Resolution**  At 18:14 UTC on September 7, 2025 we observed increased error rates and latency for our Presence service in our San Jose, Virginia, and Tokyo regions. We increased capacity in those regions and the issue was resolved at 18:17 UTC. This issue was a recurrence of the issue [experienced on September 2, 2025](https://status.pubnub.com/incidents/1n8xk6w5y9lk), where a bug in one of our APIs allowed a request to execute an operation that exceeded assumed limits in extreme cases, causing out-of-memory conditions for the Presence service. ### **Mitigation Steps and Recommended Future Preventative Measures**  In the previous instance of this issue, we placed restrictions on the API in question; those changes were not restrictive enough, which https://stspg.io/r89qvm24jzdvpubnub:2025-09-02T18:34:31.140ZTue, 02 Sep 2025 18:34:31 +0000### **Problem Description, Impact, and Resolution**  At 18:09 UTC on September 2, 2025 we observed increased error rates and latency for our Presence service in our San Jose, Virginia, and Tokyo regions. We increased capacity in those regions and the issue was resolved at 18:16 UTC. This issue occurred because a bug in one of our APIs allowed a request to execute an operation that exceeded assumed limits in extreme cases. In this case, a large number of such requests were executed that resulted in out-of-memory conditions for the Presence service. ### **Mitigation Steps and Recommended Future Preventative Measures**  To prevent a similar issue from occurring in the future we have enforced the intended limit on the API in question. We have also added additional testing and monitoring in