PubNub Outage History

Started Oct 22, 2026, 04:02 PM UTC· resolved Oct 22, 2026, 04:35 PM UTC

1. investigating Oct 22, 2026, 04:02 PM UTC

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

2. identified Oct 22, 2026, 04:12 PM UTC

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

3. monitoring Oct 22, 2026, 04:19 PM UTC

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

4. resolved Oct 22, 2026, 04:35 PM UTC

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

Read the full incident report →

Started Oct 22, 2026, 01:11 AM UTC· resolved Oct 22, 2026, 02:47 AM UTC

1. investigating Oct 22, 2026, 01:11 AM UTC

   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.

2. investigating Oct 22, 2026, 01:17 AM UTC

   We are continuing to investigate this issue.

3. identified Oct 22, 2026, 01:55 AM UTC

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

4. monitoring Oct 22, 2026, 02:12 AM UTC

   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.

5. resolved Oct 22, 2026, 02:47 AM UTC

   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.

Read the full incident report →

Started Oct 09, 2026, 05:30 PM UTC· resolved Oct 09, 2026, 06:20 PM UTC

1. resolved Oct 09, 2026, 06:45 PM UTC

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

2. postmortem Oct 14, 2026, 05:19 PM 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.

Read the full incident report →

Started Aug 25, 2026, 01:22 PM UTC· resolved Aug 25, 2026, 02:51 PM UTC

1. investigating Aug 25, 2026, 01:22 PM UTC

   As of 12:15 UTC, Users in our US East PoP are currently experiencing an issue with Publish and Subscribe service that is causing some messages to not appear in calls to that service. No errors are being returned from the service, despite messages not being returned correctly. We are investigating the issue.

2. monitoring Aug 25, 2026, 02:10 PM UTC

   As of 13:55 UTC, the issue affecting Publish and Subscribe services in the US East PoP has been mitigated. Synthetic monitoring has returned to normal, and no missed messages have been detected. The incident is currently believed to have been related to a monitoring failure. Further investigation is ongoing, and the service continues to be monitored closely.

3. resolved Aug 25, 2026, 02:51 PM UTC

   With no further issues observed for the past 30 minutes, the incident has been resolved. We will follow up soon with a root cause analysis. If you believe you experienced an impact related to this incident, please report it to PubNub Support at [email protected].

4. postmortem Aug 28, 2026, 05:46 PM UTC

   ### **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 our publishing layer. This presented no problem for the most part. However, one address was subsequently reassigned to an unrelated internal component that responded normally on the same protocol and port. Because that response appeared successful, the publishing layer received no error, and messages sent to that address were routed incorrectly. A rolling restart of the affected servers cleared the outdated addresses at 13:25 UTC. ### **Mitigation Steps and Recommended Future Preventative Measures** * Once the affected servers were identified, a rolling restart was performed to clear the outdated routing addresses. * Following an investigation that confirmed the root cause, a fix ensuring outdated internal routing addresses are correctly retired was deployed to all publishing servers worldwide on August 25th, 2026 at 22:00 UTC.

Read the full incident report →

Started Aug 14, 2026, 01:55 PM UTC· resolved Aug 14, 2026, 02:15 PM UTC

1. resolved Aug 14, 2026, 02:29 PM UTC

   From 13:55 to 14:15 UTC, users globally may have experienced errors with failure on Publish, and published messages may not have been received by subscribers. We also experienced errors and failures with PubNub Functions, and delays with Events & Actions during the period. Services have returned to normal and we are actively monitoring. A root cause analysis will be published in the coming days. If you believe you were impacted and would like to speak with us, please report impact to [email protected].

2. postmortem Aug 20, 2026, 04:57 PM UTC

   ### **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 issue by adjusting targeted traffic controls, increasing capacity for affected publish and replication components, and isolating the high-volume traffic pattern to reduce broader platform impact. The issue was resolved at approximately **14:15 UTC on Aug 14, 2026**. ‌This issue occurred because of an issue with our automated controls specific to this exceptional traffic pattern. As a result, the increased load affected multiple services before a mitigation could be fully applied. ### **Mitigation Steps and Recommended Future Preventative Measures** To prevent a similar issue from occurring in the future, we have isolated the identified high-volume traffic pattern onto dedicated infrastructure and also increased baseline capacity for the affected components across our PoPs. We are also further strengthening our traffic detection and management processes for this exceptional load pattern so it will be identified and contained earlier without cascading impact across dependent services.

Read the full incident report →

Started Jun 10, 2026, 08:14 PM UTC· resolved Jun 10, 2026, 08:45 PM UTC

1. investigating Jun 10, 2026, 08:14 PM UTC

   Starting at 17:00 UTC on June 10, a subset of publishes originating from the North America POP failed to replicate to subscribers globally. PubNub Technical Staff is investigating, and more information will be posted as it becomes available.

2. monitoring Jun 10, 2026, 08:27 PM UTC

   The PubNub Technical Staff identified that failures are limited to publishes from US-East and has identified, have applied a fix, and are now monitoring the results. If you are experiencing issues that you believe to be related to this incident, please report the details to PubNub Support ([email protected]).

3. resolved Jun 10, 2026, 08:45 PM UTC

   Services have returned to normal. A root cause analysis will be published in the coming days. If you believe you were impacted and would like to speak with us, please report impact to [email protected].

4. postmortem Jun 15, 2026, 11:58 PM UTC

   ## 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 issue from occurring in the future, we are improving the data within our health check APIs to return more complete performance metrics over a rolling time window. We are enhancing the issue detection logic to detect more patterns that infer process failure, even if the process itself is reporting as healthy.

Read the full incident report →

Started Mar 24, 2026, 08:21 PM UTC· resolved Mar 24, 2026, 09:12 PM UTC

1. investigating Mar 24, 2026, 08:21 PM UTC

   As of 19:27 UTC, we are investigating reports of connectivity issues affecting a subset of subscriptions across several global regions. While the majority of the PubNub network is operating normally, users on the affected segment may experience: - Connection delays and increased latency. - Intermittent errors when subscribing to channels. Our engineering team has identified the cause and is actively working to restore stability. We will provide updates as soon as more information is available.

2. resolved Mar 24, 2026, 09:12 PM UTC

   The incident has been resolved. If you believe you were impacted by the incident and wish to discuss it with our team, please contact us by email at [email protected]

3. postmortem Mar 25, 2026, 10:35 PM UTC

   ### **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 Recommended Future Preventative Measures** **Infrastructure Tuning:** Adjusted automated scaling parameters to provide greater headroom for rapid traffic fluctuations. **Enhanced Traffic Management:** Deployed refined monitoring heuristics to better isolate and manage high-volume traffic patterns without impacting shared resources. **Dynamic Resource Allocation:** Accelerating the rollout of enhanced vertical scaling technology to allow individual processing nodes to adapt more fluidly to demand spikes. **Operational Coordination:** Strengthening internal protocols for high-capacity events to ensure large-scale traffic shifts are proactively transitioned to dedicated environments.

Read the full incident report →

Started Jan 01, 2026, 12:25 AM UTC· resolved Jan 01, 2026, 01:00 AM UTC

1. investigating Jan 01, 2026, 12:25 AM UTC

   Starting at 12:13AM GMT, we began seeing delays in published messages being written to history storage. Users may be unable to access recently stored messages through History API calls. The messages will eventually be published. Our engineers are actively working to address the issue and we will provide updates here. If you feel your service has been impacted and you would like to discuss, please email [email protected].

2. monitoring Jan 01, 2026, 12:44 AM UTC

   A fix has been applied and we are monitoring the results. Published messages waiting on queue to be written to history have now been successfully written. We will continue to monitor for the next 15 minutes.

3. resolved Jan 01, 2026, 01:00 AM UTC

   The incident has been resolved. Published messages continue to be written to history storage normally. No messages were lost during the incident. If you believe you were impacted by the incident and wish to discuss it with our team, please contact us by email at [email protected]

4. postmortem Jan 05, 2026, 05:01 PM UTC

   ### **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. This issue occurred because we did not have proper controls in place to ensure schema consistency for newly generated monthly persistence tables. ### **Mitigation Steps and Recommended Future Preventative Measures** To resolve the issue, we manually applied the required schema updates globally. In the coming days, we will update our change management processes to ensure schema changes are correctly applied to all future monthly tables. We are also auditing our schema tracking and automating validation to prevent inconsistencies across environments. These improvements will ensure that future table generation includes all necessary columns and reduce the risk of similar issues impacting History service performance.

Read the full incident report →

Started Nov 20, 2025, 04:30 PM UTC· resolved Nov 20, 2025, 04:50 PM UTC

1. resolved Nov 20, 2025, 05:36 PM UTC

   Increased errors (5XX) observed On Nov. 20, 2025 between 16:36 UTC and 16:48 UTC, publish and replication errors (5xx) were observed in North American and Asia Pacific regions, and immediately resolved. Please contact [email protected] if you believe you were impacted by the issue and would like to discuss it with our team.

2. postmortem Nov 25, 2025, 01:05 AM UTC

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

Read the full incident report →

Started Oct 20, 2025, 01:37 PM UTC· resolved Oct 20, 2025, 11:48 PM UTC

1. investigating Oct 20, 2025, 01:37 PM UTC

   Beginning at 12:40 UTC, we observed increased latency and errors in our US-West region for multiple services. PubNub Technical Staff is currently investigating, and more updates will follow once available.

2. investigating Oct 20, 2025, 01:47 PM UTC

   We are continuing to investigate this issue.

3. investigating Oct 20, 2025, 02:21 PM UTC

   Apologies, but we are continuing to investigate this issue.

4. identified Oct 20, 2025, 02:41 PM UTC

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

5. identified Oct 20, 2025, 03:13 PM UTC

   We are still working with our infrastructure provider to mitigate the effects of the ongoing issues. We have been monitoring and handling traffic to minimize disruptions. While points of presence in the US may see slightly higher latencies, we are stable. Please reach out to PubNub support to report issues.

6. identified Oct 20, 2025, 04:43 PM UTC

   We are still stable, but seeing minor issues. We are still working with our infrastructure provider to address the remaining issues. Please reach out to PubNub support with any issues.

7. monitoring Oct 20, 2025, 05:25 PM UTC

   PubNub remains stable and fully operational. Our infrastructure provider is continuing to apply mitigation steps to restore normal health across their network and related services. We are closely monitoring the situation and coordinating with them to ensure continued stability. Please reach out to PubNub Support if you experience any service issues.

8. identified Oct 20, 2025, 05:25 PM UTC

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

9. identified Oct 20, 2025, 06:00 PM UTC

   PubNub continues to remains stable, with only minor issues being observed. Our infrastructure provider is making progress in restoring their services, with early signs of recovery in several regions. We continue to work closely with them as they complete mitigations across the remaining areas. Please reach out to PubNub Support if you experience any impact.

10. identified Oct 20, 2025, 06:37 PM UTC

    PubNub remains stable, with only minor issues being observed. Our infrastructure provider is making progress in restoring their services, with early signs of recovery in several regions. We continue to work closely with them as they complete mitigations across the remaining areas. Please reach out to PubNub Support if you experience any impact.

11. identified Oct 20, 2025, 07:06 PM UTC

    Our status is the same: stable, and working with our infrastructure provider to restore services to their normal state. Our normal policy is to update every 30 minutes, but we will stop issuing this status; we will update this page when a change to the status occurs. As always, reach out to PubNub support with any issues.

12. monitoring Oct 20, 2025, 08:25 PM UTC

    PubNub remains stable, and our infrastructure provider continues to make steady progress in restoring services. System performance and reliability are improving, and functionality across affected components is returning to normal levels. We continue to monitor closely and will share additional updates as recovery progresses. We will provide another update when there are any changes in status which we expect within the hour. Please contact PubNub Support if you experience any impact.

13. monitoring Oct 20, 2025, 10:32 PM UTC

    PubNub remains stable, and our infrastructure provider has restored normal service capacity. Systems are now operating at pre-event levels, and most dependent services are performing as expected. We continue to monitor closely and will share further updates as needed. Please contact PubNub Support if you experience any impact.

14. resolved Oct 20, 2025, 11:48 PM UTC

    This incident has been fully resolved. Our infrastructure provider has restored normal operations, and all systems are functioning as expected. Service performance and reliability have returned to pre-event levels. PubNub continues to monitor systems closely to ensure ongoing stability and we will provide an RCA in in the next couple of day. Thank you for your patience and understanding throughout this event. If you experience any further issues, please reach out to PubNub Support.

15. postmortem Oct 27, 2025, 06:33 PM UTC

    ### **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 services remained degraded for longer than expected. To restore full service, we manually reset established connections, re-routed Presence traffic to Frankfurt \(EU-Central\), and brought on additional infrastructure in other regions to absorb traffic. Errors were mitigated by 09:20 UTC. Later in the day, additional regional load in US-West triggered a new wave of service degradation. We responded by isolating the US-East region again and scaling up balancer capacity in US-West. PubNub services were stabilized by 13:20 UTC, and remained in a monitoring state while our infrastructure provider worked to fully resolve the underlying issue. By 22:35 UTC, our provider reported full restoration of service. After validating stability in US-East, we completed rebalancing traffic by 23:48 UTC, and declared the incident resolved. ### **Mitigation Steps and Recommended Future Preventative Measures** While this incident was caused by an external infrastructure outage, we’ve identified several opportunities to strengthen our internal readiness and response procedures. We are consolidating and centralizing our regional failover procedures to ensure they are immediately accessible and complete for all production services. Any gaps in our process documentation for newer services will be addressed to ensure readiness before they are fully adopted into production. Additionally, we are reviewing and resolving issues with internal tooling, including inventory and DNS resolution problems, which made mitigation more difficult during the incident. These improvements will ensure faster and more consistent responses to future infrastructure-level disruptions, and reduce potential impact on customer traffic across regions.

Read the full incident report →

Started Oct 20, 2025, 07:32 AM UTC· resolved Oct 20, 2025, 09:19 AM UTC

1. investigating Oct 20, 2025, 07:32 AM UTC

   At approximately 07:02 UTC, PubNub services began experiencing elevated latencies and server errors in the US-West and US-East regions. PubNub Technical Staff is currently investigating, and more updates will follow once available.

2. identified Oct 20, 2025, 07:58 AM UTC

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

3. monitoring Oct 20, 2025, 08:45 AM UTC

   A fix has been implemented and we are monitoring the results.

4. resolved Oct 20, 2025, 09:19 AM UTC

   With no further issues observed for the past 30 minutes, the incident has been resolved. We will follow up soon with a root cause analysis. If you believe you experienced an impact related to this incident, please report it to PubNub Support at [email protected].

5. postmortem Oct 27, 2025, 06:21 PM UTC

   ### **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 services remained degraded for longer than expected. To restore full service, we manually reset established connections, re-routed Presence traffic to Frankfurt \(EU-Central\), and brought on additional infrastructure in other regions to absorb traffic. Errors were mitigated by 09:20 UTC. Later in the day, additional regional load in US-West triggered a new wave of service degradation. We responded by isolating the US-East region again and scaling up balancer capacity in US-West. PubNub services were stabilized by 13:20 UTC, and remained in a monitoring state while our infrastructure provider worked to fully resolve the underlying issue. By 22:35 UTC, our provider reported full restoration of service. After validating stability in US-East, we completed rebalancing traffic by 23:48 UTC, and declared the incident resolved. ### **Mitigation Steps and Recommended Future Preventative Measures** While this incident was caused by an external infrastructure outage, we’ve identified several opportunities to strengthen our internal readiness and response procedures. We are consolidating and centralizing our regional failover procedures to ensure they are immediately accessible and complete for all production services. Any gaps in our process documentation for newer services will be addressed to ensure readiness before they are fully adopted into production. Additionally, we are reviewing and resolving issues with internal tooling, including inventory and DNS resolution problems, which made mitigation more difficult during the incident. These improvements will ensure faster and more consistent responses to future infrastructure-level disruptions, and reduce potential impact on customer traffic across regions.

Read the full incident report →

Started Oct 17, 2025, 06:42 AM UTC· resolved Oct 17, 2025, 08:06 AM UTC

1. investigating Oct 17, 2025, 06:42 AM UTC

   We are currently investigating an incident that could lead to some missed messages by subscribers in the IAD region. All messages are being received and persisted, and can be retrieved from the Storage service. This incident started around 22:07 UTC (03:07 PDT) on 16th Oct 2025. We suspect a moderate impact. Please report any impact related to this incident to [email protected] with any details that you can provide.

2. identified Oct 17, 2025, 06:48 AM UTC

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

3. monitoring Oct 17, 2025, 07:08 AM UTC

   A fix has been implemented and we are monitoring the results.

4. resolved Oct 17, 2025, 08:06 AM UTC

   There have been no further issues for the past 45 minutes. We are resolving this issue, and we will follow up with a post-mortem soon.

5. postmortem Oct 22, 2025, 10:20 PM UTC

   ### **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 this issue sooner, delaying detection. ### **Mitigation Steps and Recommended Future Preventative Measures** To prevent a similar issue from occurring in the future, our engineering teams have written a simpler and more reliable replacement for the faulty logic. That code is currently undergoing rigorous testing before being reintroduced in a future release. We are also addressing the lack of proper alerting that contributed to a delayed response. Synthetic tests have been reviewed, and appropriate alerting will be implemented to ensure similar regressions are detected earlier. In parallel, we are updating our development and testing processes to catch such issues before code reaches production. Lastly, we are conducting a refresher training on our incident response process to ensure faster execution and coordination in the future.

Read the full incident report →

Started Oct 06, 2025, 10:13 AM UTC· resolved Oct 06, 2025, 11:00 AM UTC

1. investigating Oct 06, 2025, 10:13 AM UTC

   At about 08:40 UTC, the Event & Action publish operation began to experience elevated error rates. Our Technical Staff is actively investigating, and more information will be posted as it becomes available. If you are experiencing issues that you believe are related to this incident, please report the details to PubNub Support ([email protected]).

2. identified Oct 06, 2025, 10:34 AM UTC

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

3. monitoring Oct 06, 2025, 10:36 AM UTC

   A fix has been implemented and we are monitoring the results.

4. resolved Oct 06, 2025, 11:00 AM UTC

   With no further issues observed, the incident has been resolved. We will follow up soon with a root cause analysis. If you believe you experienced an impact related to this incident, please report it to PubNub Support at [email protected].

5. postmortem Oct 06, 2025, 08:37 PM UTC

   ### **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 stall. Additionally, the alerting system in place was not configured to detect this failure mode promptly, delaying our response. ### **Mitigation Steps and Recommended Future Preventative Measures** To reduce the risk of similar delays in the future, we are refining our alert thresholds and naming conventions to improve early detection and clarity during response. We are also reviewing validation logic to ensure malformed messages are consistently isolated before reaching backend queues.

Read the full incident report →

Started Sep 07, 2025, 06:45 PM UTC· resolved Sep 07, 2025, 07:02 PM UTC

1. monitoring Sep 07, 2025, 06:45 PM UTC

   We experienced increased latencies and error rates in our Tokyo, San Jose, and Virginia points-of-presence from 18:14 - 18:17 UTC. A fix was deployed and we are monitoring the situation.

2. resolved Sep 07, 2025, 07:02 PM UTC

   The issues affected the Presence service from 18:14 - 18:17 UTC. We will follow up with a post-mortem soon. We apologize for the impact this may have had on your service. Please reach out to us by contacting PubNub Support ([email protected]) if you wish to discuss the impact on your service.

3. postmortem Sep 12, 2025, 11:19 PM UTC

   ### **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 allowed for this recurrence. We have corrected that oversight, as well as increased memory capacities in this area of our system as an additional safeguard.

Read the full incident report →

Started Sep 02, 2025, 06:34 PM UTC· resolved Sep 02, 2025, 06:50 PM UTC

1. monitoring Sep 02, 2025, 06:34 PM UTC

   At about 11:09, the Presence began to experience elevated latencies and error rates. PubNub Technical Staff is investigating and more information will be posted as it becomes available. If you are experiencing issues that you believe to be related to this incident, please report the details to PubNub Support ([email protected]).

2. resolved Sep 02, 2025, 06:50 PM UTC

   The issues affected the Presence service from 18:08 to 18:16 UTC. We will follow up with a post-mortem soon. We apologize for the impact this may have had on your service. Please reach out to us by contacting PubNub Support ([email protected]) if you wish to discuss the impact on your service.

3. postmortem Sep 05, 2025, 10:27 PM UTC

   ### **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 this area.

Read the full incident report →

Started Jul 31, 2025, 10:14 PM UTC· resolved Jul 31, 2025, 11:14 PM UTC

1. investigating Jul 31, 2025, 10:14 PM UTC

   We have detected elevated error levels with the Presence service in multiple regions. Our Engineers are actively working to mitigate the issues and return service to normal levels. We will provide updates here. If you believe you have been impacted by the issue, please report impact to [email protected].

2. identified Jul 31, 2025, 10:36 PM UTC

   The issue has been identified and a fix is being implemented. We will provide updates here as progress is made.

3. monitoring Jul 31, 2025, 10:44 PM UTC

   A fix has been implemented and we are monitoring the results.

4. resolved Jul 31, 2025, 11:14 PM UTC

   With no further issues observed, the incident has been resolved. We will follow up soon with a root cause analysis. If you believe you experienced an impact related to this incident, please report it to PubNub Support at [email protected].

5. postmortem Aug 04, 2025, 03:26 PM UTC

   ### **Problem Description, Impact, and Resolution** On August 1, 2025 at 22:15 UTC, we observed elevated 5xx errors across the Presence service in multiple regions. Customers may have experienced intermittent failures when attempting to receive or update presence messages. We identified a subset of channels exhibiting highly concentrated activity patterns and applied a targeted configuration change to rebalance traffic across the cluster. The issue was resolved by 23:15 UTC on August 1, 2025. This issue occurred because our infrastructure lacked proactive safeguards to evenly distribute presence traffic across nodes in scenarios where a small number of channels receive a disproportionately high number of presence updates. This resulted in resource saturation on some nodes without triggering early mitigation. ### **Mitigation Steps and Recommended Future Preventative Measures** To prevent a similar issue from occurring in the future, we have applied a sharding configuration to affected channel patterns, which redistributes load more evenly across infrastructure components. This approach reduces the risk of overload caused by concentrated traffic. In the coming days we will be: * Reviewing long-term suitability of the sharding configuration applied during this incident. * Investigating automation options for dynamically applying sharding logic based on real-time usage patterns. * Enhancing internal tooling and monitoring to better detect and respond to load imbalance scenarios before they cause service degradation.

Read the full incident report →

Started Jul 24, 2025, 02:43 PM UTC· resolved Jul 24, 2025, 03:59 PM UTC

1. resolved Jul 26, 2025, 12:16 AM UTC

   Between 15:33-15:59 UTC we observed elevated levels of latency and errors with our presence service in our FRA region. The issue has been resolved and remains stable. We apologize for the impact this may have had on your service. Please reach out to us by contacting PubNub Support ([email protected]) if you wish to discuss the impact on your service.

2. postmortem Jul 26, 2025, 12:19 AM UTC

   ### **Problem Description, Impact, and Resolution** At 14:43 UTC on July 22, 2025, we observed elevated latency and service degradation in our Presence system in the FRA region, impacting customers' ability to receive timely presence events. We implemented changes in our infrastructure to mitigate the pressure on the system, and the incident ended at 15:06 UTC on July 22, 2025. Unfortunately, before we were able to conclusively determine and address the root cause, the issue re-occurred from 15:33 to 15:59 UTC on July 24, 2025. The failures started with an out-of-memory condition in some Presence service nodes. The root cause of the memory condition was a caching system—operated by a third-party vendor—that we rely heavily on for this service began responding slowly at first, and later timing out. While nodes that run into critical issues are generally taken out of service and replaced automatically, this issue began affecting our system faster than new capacity could be brought online to mitigate the incident. Furthermore, a bug in a downstream internal system caused it to also experience failures under the pressure due to a misconfiguration in how it retried failed requests caused by the Presence system’s issues. On the 22nd, we took manual action to break the retry cycle, scale capacity, and allow the Presence service to recover. On the 24th, we identified and addressed the root cause at the caching layer. ### **Mitigation Steps and Recommended Future Preventative Measures** In the short term, we have scaled the capacity of the Presence system and we implemented changes in the affected caching layer to mitigate the issue of the vendor-provided cache system. Longer term, we are working with the vendor to fix their underlying issue, while also exploring alternatives. We also changed the retry configuration to prevent this kind of retry storm from happening again. We implemented monitoring and alerts for this failure mode, to allow us to more quickly identify this kind of issue.

Read the full incident report →

Started Jul 22, 2025, 02:43 PM UTC· resolved Jul 22, 2025, 03:59 PM UTC

1. resolved Jul 22, 2025, 06:18 PM UTC

   Between 14:43-15:06 UTC we observed intermittent spikes in errors and latency with our presence service in our FRA region. The issue has been resolved and remains stable.

2. postmortem Jul 26, 2025, 12:20 AM UTC

   ### **Problem Description, Impact, and Resolution** At 14:43 UTC on July 22, 2025, we observed elevated latency and service degradation in our Presence system in the FRA region, impacting customers' ability to receive timely presence events. We implemented changes in our infrastructure to mitigate the pressure on the system, and the incident ended at 15:06 UTC on July 22, 2025. Unfortunately, before we were able to conclusively determine and address the root cause, the issue re-occurred from 15:33 to 15:59 UTC on July 24, 2025. The failures started with an out-of-memory condition in some Presence service nodes. The root cause of the memory condition was a caching system—operated by a third-party vendor—that we rely heavily on for this service began responding slowly at first, and later timing out. While nodes that run into critical issues are generally taken out of service and replaced automatically, this issue began affecting our system faster than new capacity could be brought online to mitigate the incident. Furthermore, a bug in a downstream internal system caused it to also experience failures under the pressure due to a misconfiguration in how it retried failed requests caused by the Presence system’s issues. On the 22nd, we took manual action to break the retry cycle, scale capacity, and allow the Presence service to recover. On the 24th, we identified and addressed the root cause at the caching layer. ### **Mitigation Steps and Recommended Future Preventative Measures** In the short term, we have scaled the capacity of the Presence system and we implemented changes in the affected caching layer to mitigate the issue of the vendor-provided cache system. Longer term, we are working with the vendor to fix their underlying issue, while also exploring alternatives. We also changed the retry configuration to prevent this kind of retry storm from happening again. We implemented monitoring and alerts for this failure mode, to allow us to more quickly identify this kind of issue.

Read the full incident report →

Started Jul 08, 2025, 05:36 PM UTC· resolved Jul 08, 2025, 06:16 PM UTC

1. investigating Jul 08, 2025, 05:36 PM UTC

   At approximately 17:18 UTC, PubNub Presence services began experiencing elevated latencies and server errors in the Asia Pacific-North and US regions. PubNub Technical Staff is currently investigating, and more updates will follow once available.

2. investigating Jul 08, 2025, 05:39 PM UTC

   We are continuing to investigate this issue.

3. monitoring Jul 08, 2025, 05:46 PM UTC

   Services have returned to normal and we will continue monitoring for the next 30 minutes.

4. resolved Jul 08, 2025, 06:16 PM UTC

   With no further issues observed for the past 30 minutes, the incident has been resolved. We will follow up soon with a root cause analysis. If you believe you experienced an impact related to this incident, please report it to PubNub Support at [email protected].

5. postmortem Jul 09, 2025, 12:47 AM UTC

   ### **Problem Description, Impact, and Resolution** On July 8, 2025 at 17:15 UTC on, we observed elevated errors and increased latency for customers using our Presence service in the US East, US West, and Tokyo regions. We identified an abnormal concentration of traffic and applied a configuration change to redistribute load across our infrastructure. The issue was resolved by 17:45 UTC the same day. ### **Mitigation Steps and Recommended Future Preventative Measures** To prevent a similar issue from occurring in the future, we have implemented targeted balancing for Presence traffic patterns that exhibit such a concentrated load. This allows us to distribute traffic more evenly across infrastructure components. In the coming days, we will work to identify additional patterns that may require similar configuration changes to ensure even load balancing.

Read the full incident report →

Started Jun 30, 2025, 01:39 PM UTC· resolved Jun 30, 2025, 03:01 PM UTC

1. investigating Jun 30, 2025, 01:39 PM UTC

   At approximately 13:11 UTC, PubNub services began experiencing elevated latencies and server errors in the Europe & North US region. PubNub Technical Staff is currently investigating, and more updates will follow once available.

2. identified Jun 30, 2025, 02:01 PM UTC

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

3. monitoring Jun 30, 2025, 02:19 PM UTC

   A fix has been implemented and we are monitoring the results.

4. resolved Jun 30, 2025, 03:01 PM UTC

   With no further issues observed, the incident has been resolved. We will follow up soon with a root cause analysis. If you believe you experienced an impact related to this incident, please report it to PubNub Support at [email protected].

5. postmortem Jul 03, 2025, 06:51 PM UTC

   Beginning on Friday, June 27, 2025 at 08:15 UTC, there were occasional, intermittent increases in latency and errors in three of our services: Pub/Sub, History, and Presence. The root cause discussed in this analysis was identified and corrected on Monday, June 30. ### **Problem Description, Impact, and Resolution** Recently, to ensure PubNub had access to more cloud server capacity across our many regions, we introduced new instance types to our system to provide a more heterogeneous set of instance types on which PubNub’s services run. Over time, PubNub has created many OS/kernel-level configurations to optimize the performance of each server. However, with the more heterogeneous instance types, an underlying setting that we were explicitly specifying, which controls limits on network connectivity, was being silently overridden by our upstream load balancers. When we introduced the new instance types, they would reach connectivity limits. Unfortunately, the errors we initially encountered pointed us in incorrect directions, causing the investigation to take longer than we normally strive for. The issue was mitigated once we identified this issue and configured the affected services to run on other instance types and launched more capacity. ### **Mitigation Steps and Recommended Future Preventative Measures** To prevent recurrence, we modified the new instance types to emit metrics related to these OS thresholds and limits, enabling us to detect when these limits are approached or exceeded, regardless of instance type. This change allows us to scale proactively and properly route traffic based on instance type, ensuring we are more dynamic in heterogenous instance type deployment configuration. Again, we apologize for the incidents outlined above and are committed to maintaining transparency when issues affect our customers. Should you have any questions regarding this analysis, please reach out to our support team at [[email protected]](mailto:[email protected]).

Read the full incident report →

Started Jun 29, 2025, 04:00 PM UTC· resolved Jun 29, 2025, 04:28 PM UTC

1. resolved Jun 29, 2025, 05:15 PM UTC

   On June 29, 2025 around 16:00 UTC we began seeing elevated latency and increased errors globally across all services. Our Engineers scaled-up resources and PubNub services returned to normal levels by 16:28 UTC.

2. postmortem Jul 03, 2025, 06:50 PM UTC

   Beginning on Friday, June 27, 2025 at 08:15 UTC, there were occasional, intermittent increases in latency and errors in three of our services: Pub/Sub, History, and Presence. The root cause discussed in this analysis was identified and corrected on Monday, June 30. ### **Problem Description, Impact, and Resolution** Recently, to ensure PubNub had access to more cloud server capacity across our many regions, we introduced new instance types to our system to provide a more heterogeneous set of instance types on which PubNub’s services run. Over time, PubNub has created many OS/kernel-level configurations to optimize the performance of each server. However, with the more heterogeneous instance types, an underlying setting that we were explicitly specifying, which controls limits on network connectivity, was being silently overridden by our upstream load balancers. When we introduced the new instance types, they would reach connectivity limits. Unfortunately, the errors we initially encountered pointed us in incorrect directions, causing the investigation to take longer than we normally strive for. The issue was mitigated once we identified this issue and configured the affected services to run on other instance types and launched more capacity. ### **Mitigation Steps and Recommended Future Preventative Measures** To prevent recurrence, we modified the new instance types to emit metrics related to these OS thresholds and limits, enabling us to detect when these limits are approached or exceeded, regardless of instance type. This change allows us to scale proactively and properly route traffic based on instance type, ensuring we are more dynamic in heterogenous instance type deployment configuration. Again, we apologize for the incidents outlined above and are committed to maintaining transparency when issues affect our customers. Should you have any questions regarding this analysis, please reach out to our support team at [[email protected]](mailto:[email protected]).

Read the full incident report →

Started Jun 27, 2025, 02:02 PM UTC· resolved Jun 27, 2025, 02:09 PM UTC

1. resolved Jun 27, 2025, 03:52 PM UTC

   At approximately 14:02 - 14:09 UTC, PubNub services began experiencing elevated latencies and server errors in the Europe region. PubNub Technical Staff is investigated and the issue has resolved

2. postmortem Jul 03, 2025, 06:50 PM UTC

   Beginning on Friday, June 27, 2025 at 08:15 UTC, there were occasional, intermittent increases in latency and errors in three of our services: Pub/Sub, History, and Presence. The root cause discussed in this analysis was identified and corrected on Monday, June 30. ### **Problem Description, Impact, and Resolution** Recently, to ensure PubNub had access to more cloud server capacity across our many regions, we introduced new instance types to our system to provide a more heterogeneous set of instance types on which PubNub’s services run. Over time, PubNub has created many OS/kernel-level configurations to optimize the performance of each server. However, with the more heterogeneous instance types, an underlying setting that we were explicitly specifying, which controls limits on network connectivity, was being silently overridden by our upstream load balancers. When we introduced the new instance types, they would reach connectivity limits. Unfortunately, the errors we initially encountered pointed us in incorrect directions, causing the investigation to take longer than we normally strive for. The issue was mitigated once we identified this issue and configured the affected services to run on other instance types and launched more capacity. ### **Mitigation Steps and Recommended Future Preventative Measures** To prevent recurrence, we modified the new instance types to emit metrics related to these OS thresholds and limits, enabling us to detect when these limits are approached or exceeded, regardless of instance type. This change allows us to scale proactively and properly route traffic based on instance type, ensuring we are more dynamic in heterogenous instance type deployment configuration. Again, we apologize for the incidents outlined above and are committed to maintaining transparency when issues affect our customers. Should you have any questions regarding this analysis, please reach out to our support team at [[email protected]](mailto:[email protected]).

Read the full incident report →

Started Jun 10, 2025, 06:30 PM UTC· resolved Jun 10, 2025, 07:07 PM UTC

1. resolved Jun 10, 2025, 08:16 PM UTC

   Beginning at 18:33 UTC we observed increased latency and errors for our History service in one of our North America regions. Users in the affected region may have experienced failures with error or latency when making calls to the History endpoint. The issue has been resolved as of 19:07 UTC. We will publish a root cause analysis within the coming days. We sincerely apologize for any impact caused to your PubNub services. If you feel you have been impacted by the issue and wish to report it, please contact [email protected].

2. postmortem Jun 23, 2025, 05:42 PM UTC

   ### **Problem Description, Impact, and Resolution** On June 10, 2025 at 18:33 UTC, we observed elevated error rates and increased latency for a subset of traffic for the History service in the US East region. Customers using the History API in this region may have encountered read failures or timeouts during this window. We identified transient connection issues with infrastructure supported by a third-party provider service. We quickly escalated the issue, working with the provider to identify and mitigate the root cause. Service performance returned to normal levels, and the issue was resolved by 19:07 UTC the same day. ### **Mitigation Steps and Recommended Future Preventative Measures** To improve the resilience of the History service and prevent such issues from recurring in the future, we have upgraded backend storage systems and deployed updated versions of our History mechanisms globally. These updates improve compatibility with recent infrastructure changes and enhance the reliability of backend connectivity. In the coming weeks, we are also evaluating a modernization of the History service architecture to further improve long-term stability and performance.

Read the full incident report →

Started Jun 02, 2025, 12:20 PM UTC· resolved Jun 02, 2025, 01:51 PM UTC

1. resolved Jun 02, 2025, 02:43 PM UTC

   Starting at 12:20 UTC, we noticed an increase in errors and latency affecting the Presence service in the BOM and FRA regions. Our engineers investigated the issue and successfully restored the service completely, which has remained stable since 13:51 UTC.

2. postmortem Jun 03, 2025, 05:10 PM UTC

   ### Problem Description, Impact, and Resolution Starting at 12:20 pm UTC on June 2, 2025, we noticed an increase in errors and latency affecting the Presence service in multiple regions. After investigating the increase in errors and latency, we identified the cause to be a higher-than-normal traffic pattern. In response, we scaled up resources to handle the request load, and the Presence service was fully restored in the affected regions by 1:51 PM UTC on June 2, 2025. ### Mitigation Steps and Recommended Future Preventative Measures To prevent a similar issue from occurring in the future, we are tuning our autoscaling configuration, as well as analyzing system behavior and bottlenecks observed during the incident window to inform further adjustments.

Read the full incident report →

Started May 22, 2025, 08:51 PM UTC· resolved May 22, 2025, 09:04 PM UTC

1. resolved May 22, 2025, 09:34 PM UTC

   Beginning at 20:51 UTC, we detected increased errors and latency for traffic within a single availability zone in the US East region. Our engineers investigated the issue and successfully restored service, which has remained stable since 21:04 UTC.

2. postmortem May 28, 2025, 10:15 PM UTC

   ### **Problem Description, Impact, and Resolution** On May 23, 2025 at 20:51 UTC, PubNub experienced increased errors and latency for a subset of traffic within a single availability zone in the US East region. The root cause was an operational error during an infrastructure change. We unintentionally drained traffic from newly deployed load balancers. As a result, the system routed traffic incorrectly, causing elevated error rates and latency for some users. Once the issue was identified, traffic was rerouted, and service performance returned to normal levels. The incident was resolved by 21:04 UTC the same day. ### **Mitigation Steps and Recommended Future Preventative Measures** To prevent the issue from recurring in the future, the change procedure has been updated to reference isolated, non-production resources during preparation stages. If run prematurely, the script will now operate on an empty set, ensuring no production traffic is impacted.

Read the full incident report →