57 Pubnub incidents · 2023년 3월 — official updates, affected components, duration and resolution details.
사용자는 프랑크푸르트 지점의 역사 리더와 높은 오류를 경험할 수 있습니다. 우리는 치료에 일하고 우리가 진전을 만들기 때문에 이것을 업데이트할 것입니다. 당신이 영향을 받고 토론하고 싶으면 [email protected]으로 연락하십시오
수정이 구현되어 결과를 모니터링하고 있습니다. 이 영향을 받으면 [email protected]으로 연락하십시오.
이 사건은 해결되었습니다. 충격을 느끼면 [email protected]으로 문의하십시오.
공식 인시던트 업데이트를 자동 번역했습니다.
사용자는 Presence API를 사용하여 높은 오류 및 대기 시간이 발생할 수 있습니다. 우리는 치료에 일하고 우리가 진전을 만들기 때문에 이것을 업데이트할 것입니다. 당신이 영향을 받고 토론하고 싶으면 [email protected]으로 연락하십시오
이 문제에 대한 수정은 구현되었으며 결과를 모니터링하고 있습니다. 이 영향을 받으면 [email protected]으로 연락하십시오.
우리는 더 많은 문제를 모니터링하고 있습니다.
이 사건은 해결되었습니다, 우리는 postmortem로 위로 따를 것입니다. 질문이 있거나 우려 사항이 있으시면 [email protected]으로 문의하십시오.
공식 인시던트 업데이트를 자동 번역했습니다.
사용자는 프랑크푸르트와 Bombay Point-of-presence에서 높은 오류 및 대기 시간이 발생할 수 있습니다. 우리는 치료에 일하고 우리가 진전을 만들기 때문에 이것을 업데이트할 것입니다. 영향을 받으면 [email protected]으로 연락하십시오.
문제는 식별되고 수정이 구현됩니다.
수정이 구현되어 결과를 모니터링하고 있습니다. 이 문제에 영향을 미쳤거나 여전히 영향을 미쳤다면 [email protected]으로 연락하십시오.
이 사건은 해결되었습니다. 충격을 느끼면 [email protected]으로 문의하십시오.
###**Problem 묘사, 충격 및 해결책 ** 10월 22일, 약 14:45에서 16:13 UTC, 우리의 프랑크푸르트의 사용자 \ (FRA\) 및 뭄바이 \ (BOM\) 존재의 포인트는 Presence API 통화에 대한 높은 오류율과 대기 시간을 볼 수 있습니다. 다른 PubNub 서비스는 영향을받지 않았습니다. 이 문제는 프랑크푸르트의 Presence 서비스에 소프트웨어 업데이트 중 시작되었습니다. 새 버전은 이전 버전과 호환되지 않았습니다. 둘 다 동시에 실행되었습니다. 그 때문에 지역에있는 Presence 서버가 반복적으로 재시작하고 건강한 서버가 오류에 도달 할 수없는 요청. 우리의 팀은 원인으로 업데이트를 확인하고 다시 압연. 서비스는 대략 16:13 UTC에 정상으로 돌려받습니다. # # # ** 소송 단계 및 권장 미래 예방 조치 ** 이 업데이트 전에 호환성을 수정하고 있습니다. 우리는 또한 모든 존재 방출의 앞에 측에 의하여 이전과 새로운 버전 측을 달리는 시험 추가하고, 한 번에 갱신 1개의 가용성 지역을 구르고, 우리의 rollback 절차를 개량합니다 그래서 그것은 호환이 되는 버전을 함께 달리지 않습니다.
공식 인시던트 업데이트를 자동 번역했습니다.
보안 인증서를 업데이트하는 오류는 연결 문제가 발생할 수 있습니다. 우리는 투자하고 우리가 더 알아내는 것과 같이 새롭게 할 것입니다.
이 문제를 조사하고 있습니다.
우리는 문제점을 확인하고 치료로 잘 알려져 있습니다. 문제가 발생할 경우 [email protected]으로 연락하십시오.
우리는이 문제에 대한 교훈을 완료했습니다. 충격은 미성년자이었습니다: 단지 1개의 최종 사용자는 문제점을 보고했습니다, 그러나 우리는 추가 충격을 감시하고 있습니다. 이메일: [email protected].
우리는이 문제에 대한 추가 보고서가 없었다. 충격을 느끼면 [email protected]으로 문의하십시오. post-mortem는 따릅니다.
###**Problem 묘사, 충격 및 해결책 ** 에서 19:26 UTC 에 10월 21 까지 약 02:04 UTC 에 10월 22, 일부 PubNub 엔드 포인트 제공 TLS 인증서 우리의 인증서 권한이 변경되었다. 인증서 재발급을 확인하는 클라이언트는 해당 창에서 영향을받은 엔드포인트에 연결하지 못했습니다. 우리의 인증서 기관은 출판 된 인증서 정책 정책과 일치하지 않은 포함 된 정책 정보를 발행 한 약 400,000 인증서를 발견했습니다. 인증서는 타협하지 않았지만 업계 규정은 이러한 인증서를 수정하고 교체해야합니다. PubNub의 인증서 \*.pubnub.com, \*.pubnub.net, \*.pndsn.com 및 \*.pubnubapi.com 중 하나이며 10 월 21 일에 개정되었습니다. 우리의 교체 인증서는 철회가 효력을 발생했을 때까지 우리의 모든 엔드포인트에 배포되지 않았습니다. 인증서 재발급을 확인하지 않는 클라이언트는 영향을받지 않았으며, 기본 SDK Origin [ps.pndsn.com](http://ps.pndsn.com)에 연결되었습니다. 고객의 최종 사용자에 의해 경고되었습니다. 10월 22일 오후 02:04 UTC에 완료된 모든 지역에 교체 인증서를 배포했습니다. Hostnames 및 인증서 만료일 \(1 월 7, 2027 \)는 변경되지 않습니다. # # # ** 소송 단계 및 권장 미래 예방 조치 ** 우리는 우리가 봉사하는 어떤 증명서든지 있으면 우리의 가동 팀을 경고하는 감시를 추가하고 있습니다. 우리는 또한 우리의 인증서 교체 프로세스를 변경 그래서 교체는 생산에 신속하게 한 번 발행, 그래서 인증서 업데이트는 모든 지역을 빠르게 도달.
공식 인시던트 업데이트를 자동 번역했습니다.
시작 17:32 UTC 에 10월 9, 2026 우리는 상승을 관찰 5XX 오류율과 전 세계 구독의 대기 시간. 문제는 18:18 UTC에 의해 해결되고 서비스는 정상 수준으로 돌아 왔습니다. 고객의 제한된 수는 영향을 미칠 수 있습니다. 뿌리 원인 분석은 다가오는 날에 게시됩니다. 우리는 진심으로이 발생 할 수있는 영향에 대한 사과. 영향을 받고 논의하고자 하는 경우 [email protected]으로 이메일을 보내주십시오.
###**Problem 묘사, 충격 및 해결책 ** 10월 9일, 2026일, 17시 반과 18시 20분 UTC 사이, 우리는 고객의 하위 세트에 대한 구독 엔드포인트에 영향을 미치는 HTTP 5xx 오류를 관찰했다. 일부 구독 요청은 실패 할 수 있으며 메시지의 하위 세트가 지연되거나 실제 시간에 전달되지 않을 수 있습니다. 메시지가 분실되지 않았고, 메시지 Persistence를 통해 고객은 역사에서 영향을받는 메시지를 검색 할 수 있습니다. 이 사건은 예상한 제한이 없는 개발 키셋에 대한 고량 부하 테스트에서 트래픽의 예상치 못한 증가로 인해 발생했습니다. 일부 공유 된 인프라에서 일시적으로 배출 된 메모리의 결과로 문제가 발생했습니다. 우리는 초과 부하를 생성하는 키셋에 대한 비율 제한을 적용하여 영향을받는 인프라를 안정화했습니다. 서비스는 18:20 UTC에 의해 정상으로 반환됩니다. # # # ** 소송 단계 및 권장 미래 예방 조치 ** 우리는 예상치 못한 트래픽과 복구 서비스를 포함하기 위해 임시 게시 속도 제한을 적용하고 영향을받는 keyset의 가용성을 보존하면서. 유사한 사건을 방지하기 위해 PubNub는 다른 트래픽이 동일한 인프라를 공유 할 수 있기 전에 특정 무거운 짐을 감지하고 자동으로 제한하기 위해 안전한 보호 기능을 보장하기 위해 추가 검사를 추가합니다. 우리는 또한 가입자 메모리 및 자동 확장 변경에 대한 운영 절차를 업데이트하여 용량 조정은 사건 완화 중에 효과적입니다.
공식 인시던트 업데이트를 자동 번역했습니다.
12:15 UTC로, 미국 동부 PoP의 사용자는 현재 그 서비스에 전화하지 않고 일부 메시지가 나타나지 않는 Publish 및 Subscribe 서비스로 문제가 발생합니다. 오류가 발생하지 않고 메시지가 제대로 반환되지 않습니다. 우리는 문제를 조사하고 있습니다.
13:55 UTC로, 미국 동부 PoP의 Publish 및 Subscribe 서비스에 영향을 미치는 문제가 mitigated되었습니다. 합성 감시는 정상에 돌려, 놓인 메시지가 검출되지 않았습니다. 사건은 현재 감시 실패와 관련이 있다고 믿고 있습니다. 더 많은 조사는 계속되고, 서비스는 밀접하게 감시될 것입니다.
지난 30 분 동안 관찰 된 더 이상 문제없이, 사건이 해결되었습니다. 우리는 뿌리 원인 분석으로 곧 수행됩니다. 이 사건과 관련된 영향을 얻고 싶다면 [email protected]에서 PubNub Support에 신고하십시오.
###**Problem 묘사, 충격 및 해결책 ** 화요일, 8 월 25 일, 2026, 12 : 10 UTC에서, 우리의 내부 모니터링은 한 지역의 가용성 영역 내에서 메시지의 매우 작은 하위 세트를 경고했다 \ (우리의 미국 동부 지점의 존재 \) 그 동일한 지역에 가입자에게 즉시 전달되지 않을 수 있습니다. 모든 메시지는 PubNub Persistence 서비스 내에서 일반적으로 지속되었습니다. ** 메시지 데이터가 손실되지 않았습니다. ** 다른 지역 또는 AZ의 교통은 영향을받지 않았으며 다른 PubNub 서비스가 영향을받지 않았습니다. 고객 보고 충격 없음. ###**Root 원인** 계획된 내부 짐 테스트 도중, 내부 여정 서버의 그룹은 서비스에서 제거되었습니다. 구성 결함으로 인해 네트워크 주소는 완전히 은퇴하고 우리의 출판 층에 의해 캐시되지 않았습니다. 이것은 대부분의 부분에 대한 문제가 없습니다. 그러나, 한 가지 주소는 일반적으로 동일한 프로토콜과 포트에 응답하는 관련 내부 구성 요소에 따라 다시 할당되었습니다. 응답이 성공적이기 때문에, 출판 층은 오류를받지 않고, 그 주소로 전송 된 메시지가 잘못되었습니다. 영향을받는 서버의 롤링 재시작은 13시 25분 UTC에서 삭제된 주소를 삭제했습니다. # # # ** 소송 단계 및 권장 미래 예방 조치 ** * 영향을받은 서버가 확인되면, 롤링 재시작은 routing 주소를 삭제하기 위해 수행되었습니다. * 루트 원인을 확인한 조사에 따라 수정된 내부 라우팅 주소가 제대로 은퇴된 것은 8월 25일 오후 22:00 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].
### **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.
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.
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]).
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].
## 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.
From 13:20 to 13:48 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].
### **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 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 **13:48 UTC on June 9, 2026**. This issue occurred because we did not have sufficient automated controls and isolation processes in place to protect shared infrastructure from this type of exceptional traffic pattern. As a result, the increased load affected multiple services before 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 exceptional load patterns so they can be identified and contained earlier without cascading impact across dependent services.
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.
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]
### **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.
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].
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.
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]
### **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.
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.
**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.
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.
We are continuing to investigate this issue.
Apologies, but we are continuing to investigate this issue.
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.
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.
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.
The issue has been identified and a fix is being implemented.
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.
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.
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.
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.
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.
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.
### **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.
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.
The issue has been identified and a fix is being implemented.
A fix has been implemented and we are monitoring the results.
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].
### **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.
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.
The issue has been identified and a fix is being implemented.
A fix has been implemented and we are monitoring the results.
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.
### **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.
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]).
The issue has been identified and a fix is being implemented.
A fix has been implemented and we are monitoring the results.
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].
### **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.
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.
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.
### **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.
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]).
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.
### **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.
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].
The issue has been identified and a fix is being implemented. We will provide updates here as progress is made.
A fix has been implemented and we are monitoring the results.
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].
### **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.
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.
### **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.
