Dev APIs / Realtime messaging / Pusher

Pusher

OPERATIONAL

Since Nov 2023 · 50 incidents · status.pusher.com · checked just now

User reportsVisitors who said it's down for them, per hour over 24 hours. Not from the status page. Never counted in grades.
…
CompareAdd to stackStatus page
GradeALast 90 days
APRODA+SHIP

Overview

30d90d1y
Admitted uptimeCustomer time not hit, by the provider's own account. Regional and partial incidents count in part.
99.964%Grade A
IncidentsEverything posted on the status page except scheduled maintenance.
20 Sev 1
Fully downMost customers down, by the provider's own account.
0m
Median fixMedian time to resolve. Half of incidents were fixed faster.
3h 45m
LongestLongest Sev 1–2 incident, start to resolved.
3h 45m
Since lastTime since the last counted incident was resolved.
62d 11h

By area

AProduction
2INCIDENTS
5h 15mAFFECTED
Your users are hit: apps, APIs, databases, inference
Worst, 90d
SEV 2Aug 23, 2026 · 3h 45m · some customersElevated Errors on us2
SEV 2Aug 22, 2026 · 1h 31m · regionalElevated errors on us2 cluster
Most hit
Channels REST API1
Channels WebSocket client API1
Channels presence channels1
Better. 2 in the last 6 months, 7 in the 6 before.
A+Shipping
0INCIDENTS
0mAFFECTED
You can't deploy, build or manage: CI, CLI, dashboard, auth, billing
Worst, 90dNothing.
Better. 0 in the last 6 months, 1 in the 6 before.
CleanSev 3–4Sev 1–2No data

Trend, last 12 months

Better. 2 in the last 6 months, 8 in the 6 before.

Severity mix

Sev 1 · Lights outProd site, API or database down, or data loss0
Sev 2 · BleedingProd degraded or partly down2
Sev 3 · Can't shipCan't deploy, build or manage it0
Sev 4 · PapercutDocs, status page, slow dashboard0

When it breaks

Start times, last 12 months, UTC.

What breaks

Channels presence channels5 incidents
Channels WebSocket client API4 incidents
Channels REST API3 incidents
Channels Webhooks3 incidents

Communication

Updates eachStatus page updates per incident, on average.
6.4Last 12 months
Update gapMedian time between status page updates during an incident.
24mLast 12 months
PostmortemsSev 1–2 incidents with a published write-up.
0 of 10Sev 1–2

Incident history

Aug 23, 20263h 45mSEV 2
Elevated Errors on us2Pusher's us2 cluster saw unusual traffic causing short, frequent error spikes for a small subset of requests and customers, starting 01:27 UTC on 23 August. Autoscaling absorbed the bursts and the incident was resolved about 05:12 UTC. The provider did not state a root cause.AI-graded · some customers
Why this grade
  1. RULES · SEV 2
    Sev 2 from the incident title (no components listed)
  2. CLAUDE · SEV 2 · SUBSET · MEDIUM CONFIDENCE
    Intermittent errors hit a small subset of requests on the us2 cluster for about three hours; most customers saw no impact.
  3. Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record
3 updates
  1. 01:27 UTC · investigating
    We are seeing unusual traffic on the us2 cluster that is affecting a subset of traffic. The impact is limited to certain requests, while the majority of traffic continues to operate normally. We are actively investigating the cause and working to mitigate the impact.
  2. 02:03 UTC · investigating
    We are seeing short but frequent spikes in errors affecting a small subset of traffic on the us2 cluster. The impact is intermittent and varies across customers, with the vast majority of customers experiencing no impact. Our systems have automatically scaled capacity in response to the unusual traffic bursts, and we are continuing to monitor the situation closely.
  3. 05:12 UTC · resolved
    This incident has been resolved.
Source
Aug 22, 20261h 31mSEV 2
Elevated errors on us2 clusterRealtime publish, WebSocket and presence API requests failed intermittently on the us2 cluster for about 90 minutes; other clusters were unaffected.AI-graded · regional · Channels REST API +2
Why this grade
  1. RULES · SEV 2
    Sev 2 because Channels REST API had degraded performance
  2. CLAUDE · SEV 2 · REGIONAL · MEDIUM CONFIDENCE
    Realtime publish, WebSocket and presence API requests failed intermittently on the us2 cluster for about 90 minutes; other clusters were unaffected.
  3. Claude Haiku 5.5 · prompt v8 · Oct 23, 2026 · Raw record
3 updates
  1. 03:17 UTC · investigating
    We are investigating an increased error rate affecting the us2 cluster. All services remain operational, but a subset of customers may experience intermittent issues.
  2. 03:32 UTC · monitoring
    A fix has been implemented, and we are monitoring the results. All publish requests are now succeeding.
  3. 04:47 UTC · resolved
    This incident has been resolved.
Source
Apr 6, 20261h 04mSEV 2
Intermittent API errors in US2 clusterPusher had intermittent errors on its Channels API in the US2 cluster, starting 01:52 UTC on 6 April 2026. A fix was implemented and monitored, and the incident was resolved by 02:55 UTC. The text gives no further cause detail.AI-graded · regional · Channels WebSocket client API
Why this grade
  1. RULES · SEV 2
    Sev 2 because Channels WebSocket client API had degraded performance
  2. CLAUDE · SEV 2 · REGIONAL · MEDIUM CONFIDENCE
    Channels API requests failed intermittently in the US2 cluster for about an hour; other clusters were not reported affected.
  3. Claude Haiku 5.5 · prompt v8 · Oct 23, 2026 · Raw record
4 updates
  1. 01:52 UTC · investigating
    We are currently investigating an issue with intermittent errors for the Channels API in US2 cluster.
  2. 02:01 UTC · identified
    The issue has been identified and a fix is being implemented.
  3. 02:32 UTC · monitoring
    A fix has been implemented and we are monitoring the results.
  4. 02:55 UTC · resolved
    This incident has been resolved.
Source
Mar 31, 202611mSEV 2
Cluster SA1: Delayed Channels webhook delivery on SA1 clusterChannels webhook deliveries were delayed or missed for about 11 minutes on the SA1 cluster only.AI-graded · regional · Channels Webhooks
Why this grade
  1. RULES · SEV 2
    Sev 2 because Channels Webhooks had degraded performance
  2. CLAUDE · SEV 2 · REGIONAL · MEDIUM CONFIDENCE
    Channels webhook deliveries were delayed or missed for about 11 minutes on the SA1 cluster only.
  3. Claude Haiku 5.5 · prompt v8 · Oct 23, 2026 · Raw record
3 updates
  1. 12:33 UTC · identified
    Customers on the SA1 cluster may have experienced delayed or missed webhook deliveries, including cache channel webhooks.
  2. 12:42 UTC · monitoring
    A fix has been implemented and we are monitoring the results.
  3. 12:44 UTC · resolved
    This incident has been resolved.
Source
Feb 15, 20261h 41mSEV 2
Increased error rate on the US2 clusterIncreased error rate on Pusher's US2 cluster affected only part of its traffic for about 100 minutes.AI-graded · regional
Why this grade
  1. RULES · SEV 2
    Sev 2 from the incident title (no components listed)
  2. CLAUDE · SEV 2 · REGIONAL · MEDIUM CONFIDENCE
    Increased error rate on Pusher's US2 cluster affected only part of its traffic for about 100 minutes.
  3. Claude Haiku 5.5 · prompt v8 · Oct 23, 2026 · Raw record
3 updates
  1. 20:33 UTC · investigating
    We are currently investigating this issue.
  2. 21:38 UTC · monitoring
    The fix has been implemented and we are monitoring the results. The issue affected only part of the cluster traffic. All services are currently operational
  3. 22:14 UTC · resolved
    This incident has been resolved.
Source
Jan 29, 202621mSEV 2
Errors increase for API in cluster us3Channels REST API in cluster us3 had elevated error rates for about 20 minutes; other clusters were not mentioned as affected.AI-graded · regional · Channels REST API
Why this grade
  1. RULES · SEV 2
    Sev 2 because Channels REST API had degraded performance
  2. CLAUDE · SEV 2 · REGIONAL · MEDIUM CONFIDENCE
    Channels REST API in cluster us3 had elevated error rates for about 20 minutes; other clusters were not mentioned as affected.
  3. Claude Haiku 5.5 · prompt v8 · Oct 23, 2026 · Raw record
3 updates
  1. 10:38 UTC · investigating
    We are currently investigating the issue with increased error rate for the Channels API in cluster us3
  2. 10:55 UTC · monitoring
    A fix has been implemented and we are monitoring the situation
  3. 10:58 UTC · resolved
    This incident has been resolved.
Source
Jan 26, 202614mSEV 2
Increased error rate on the US2 cluster impacting presence eventsElevated error rates on the US2 cluster hit presence channel events and webhooks for about 14 minutes; other clusters were not reported affected.AI-graded · regional · Channels presence channels +1
Why this grade
  1. RULES · SEV 2
    Sev 2 because Channels presence channels had degraded performance
  2. CLAUDE · SEV 2 · REGIONAL · MEDIUM CONFIDENCE
    Elevated error rates on the US2 cluster hit presence channel events and webhooks for about 14 minutes; other clusters were not reported affected.
  3. Claude Haiku 5.5 · prompt v8 · Oct 23, 2026 · Raw record
2 updates
  1. 22:29 UTC · investigating
    We are currently investigating this issue.
  2. 22:43 UTC · resolved
    This incident has been resolved.
Source
Jan 22, 202619h 20mSEV 3
Incorrect subscription changes affecting some accountsA limited number of accounts were wrongly downgraded to lower subscription levels by a billing error, blocking config changes for them.AI-graded · some customers · Channels REST API +1
Why this grade
  1. RULES · SEV 2
    Sev 2 because Channels REST API had degraded performance
  2. CLAUDE · SEV 3 · SUBSET · MEDIUM CONFIDENCE
    A limited number of accounts were wrongly downgraded to lower subscription levels by a billing error, blocking config changes for them.
  3. Claude Haiku 5.5 · prompt v8 · Oct 23, 2026 · Raw record
2 updates
  1. 16:38 UTC · identified
    We’ve been made aware of an issue caused by our billing provider, Maxio, where a limited number of our customer accounts were incorrectly downgraded due to an incident on their side. We are actively working with Maxio to restore all affected accounts to their correct subscription levels.
  2. 11:58 UTC · resolved
    All affected accounts have been restored to their correct subscription levels. We sent an email yesterday to all impacted customers. If you notice any issues with your subscription, please contact us.
Source
Jan 16, 20263h 52mSEV 2
Intermittent errors with message delivery on cluster us2Intermittent errors hit message delivery on presence channels in Pusher cluster us2 from about 08:48 to 12:41 UTC on 16 January 2026. A fix was implemented around 11:10 UTC and monitored before the incident was resolved. The provider gave no further root-cause detail.AI-graded · regional · Channels presence channels
Why this grade
  1. RULES · SEV 2
    Sev 2 because Channels presence channels had degraded performance
  2. CLAUDE · SEV 2 · REGIONAL · MEDIUM CONFIDENCE
    Message delivery on presence channels in cluster us2 failed intermittently for about four hours; other clusters were not reported affected.
  3. Claude Haiku 5.5 · prompt v8 · Oct 23, 2026 · Raw record
4 updates
  1. 08:48 UTC · investigating
    We are currently investigating this issue.
  2. 10:56 UTC · identified
    The issue has been identified and a fix is being implemented.
  3. 11:10 UTC · monitoring
    A fix has been implemented and we are monitoring the results.
  4. 12:41 UTC · resolved
    This incident has been resolved.
Source
Jan 16, 202631mSEV 2
Intermittent errors with message deliveryIntermittent message delivery errors on WebSocket client API and presence channels for about 30 minutes; scope not stated.AI-graded · Channels WebSocket client API +1
Why this grade
  1. RULES · SEV 2
    Sev 2 because Channels WebSocket client API had degraded performance
  2. CLAUDE · SEV 2 · UNCLEAR · MEDIUM CONFIDENCE
    Intermittent message delivery errors on WebSocket client API and presence channels for about 30 minutes; scope not stated.
  3. Claude Haiku 5.5 · prompt v8 · Oct 23, 2026 · Raw record
3 updates
  1. 01:07 UTC · investigating
    We are currently investigating this issue.
  2. 01:16 UTC · monitoring
    A fix has been implemented and we are monitoring the results.
  3. 01:37 UTC · resolved
    This incident has been resolved.
Source
Oct 27, 20251h 45mSEV 2
AP1 cluster - Socket connection failuresSocket connections in Pusher's AP1 cluster began failing around 10:00 UTC on 27 October 2025, forcing clients to reconnect. Many clients connected via fallback protocols. Unusual activity, likely from one customer's cyber attack, was mitigated while cluster resources were increased. All services were fully operational by 12:53 UTC, and the incident was resolved at 13:34 UTC.AI-graded · regional · Channels WebSocket client API +1
Why this grade
  1. RULES · SEV 2
    Sev 2 because Channels WebSocket client API had degraded performance
  2. CLAUDE · SEV 2 · REGIONAL · MEDIUM CONFIDENCE
    WebSocket and presence channel connections in the AP1 cluster were disrupted for about three hours, forcing client reconnects; other clusters were not described as affected.
  3. Claude Haiku 5.5 · prompt v8 · Oct 23, 2026 · Raw record
5 updates
  1. 11:50 UTC · investigating
    We are currently experiencing disruptions with socket connections in AP1 cluster, which began at 10:00 UTC. Clients may experience reconnections. Our team is actively investigating the issue and working to restore full connectivity as quickly as possible.
  2. 12:22 UTC · identified
    A fix is implemented. We are seeing improvements and continue to actively monitor the situation to ensure full stability. During the incident, many clients successfully connected using fallback protocols.
  3. 12:41 UTC · monitoring
    We observed unusual activity on the cluster, likely caused by at least one customer experiencing a cyber attack. Our team is mitigating the issue while simultaneously increasing cluster resources to minimize impact on other customers. The cluster availability is returning to normal. We continue to monitor closely.
  4. 12:53 UTC · monitoring
    All services are now fully operational. We continue to monitor the cluster.
  5. 13:34 UTC · resolved
    This incident has been resolved.
Source
Oct 21, 20252h 37mSEV 2
Elevated API Errors in AP4 ClusterA misconfigured Redis cache container in the AP4 cluster failed to start, causing elevated API errors and latency. Customers could not reliably publish Channels messages, and real-time delivery failed or was delayed. The cluster was fixed on October 21 and resolved at 17:43 UTC after a fix to the Redis configuration and cache restarts.AI-graded · regional · Channels REST API +2
Why this grade
  1. RULES · SEV 1
    Sev 1 because Channels REST API had a partial outage
  2. CLAUDE · SEV 2 · REGIONAL · MEDIUM CONFIDENCE
    Channels API publishing and real-time delivery failed or degraded in the AP4 cluster for about two and a half hours; other clusters stayed up.
  3. Claude Haiku 5.5 · prompt v8 · Oct 23, 2026 · Raw record
8 updates
  1. 15:06 UTC · investigating
    We're experiencing an elevated level of API errors and latency in AP4 and are currently looking into the issue.
  2. 15:09 UTC · identified
    The team has identified the issue with one of our backend caching servers. The team is working to restore the connections to the server.
  3. 15:27 UTC · identified
    The team continues to make progress restoring the cache services. We anticipate full resolution in the next 10-15 minutes.
  4. 15:29 UTC · monitoring
    A fix has been implemented and we are monitoring. The cluster will take a few more minutes to fully stabilize across all nodes.
  5. 17:32 UTC · identified
    We are currently investigating an issue affecting the Channels API. A large number of customers may be unable to publish new messages through the API in the AP4 cluster.
  6. 17:39 UTC · monitoring
    A fix has been implemented and we are monitoring the results.
  7. 17:43 UTC · resolved
    This incident has been resolved.
  8. 14:12 UTC · postmortem
    ## **Root Cause Analysis: Elevated API Errors and Outage in AP4 Cluster** **Incident Date:** October 20, 2025 **Status:** Resolved ### **Summary** Between **October 20 and October 21, 2025**, customers using the **AP4 cluster** experienced elevated API errors, latency, and message publishing failures. The issue primarily affected the **Channels API**, preventing customers from publishing new messages and leading to degraded real-time functionality for end-users. During system recovery and while implementing mitigations from a previous incident on Oct 18th, a **misconfigured Redis container** in the AP4 cluster failed to start correctly, preventing caching operations needed for API requests. This misconfiguration went undetected by proactive monitoring, delaying full recovery until October 21 at 17:43 UTC. ### **Impact** Throughout the incident period, customers in the **AP4 cluster** experienced: * **High API error rates** when attempting to publish messages through the Channels API * **Failed or delayed message delivery** for connected clients * **Temporary downtime** for end-customer applications relying on real-time messages Other clusters remained operational, though some minor latency was observed in isolated regions due to dependencies on shared services. ### **Root Cause** This incident resulted from **a chain of events** involving both external and internal factors: 1. \*\*Major AWS Outage \(October 20\)\*\*A large-scale **AWS outage in the US-East region** disrupted multiple dependent systems, impacting several Pusher clusters. 2. **Misconfigured Redis Container \(October 21\)** As systems in the AP4 cluster attempted to scale during recovery, one of the backend **Redis cache containers** failed to start due to a **misconfigured environment variable**. This prevented Redis from initializing properly, resulting in API operations failing or timing out. 3. **Monitoring Gap** Existing monitoring did not capture the **Redis startup failure** because the specific failure mode occurred after initialization checks had passed. This delayed internal detection until API error rates increased and customer impact was observed. 4. **Delayed Customer Communication** Initial updates to customers were delayed while the team triaged the issue and verified the failure pattern, prolonging the time before external notification. ### **Detection and Response** The issue was detected through a combination of **monitoring alerts** showing elevated error rates and **customer reports** of publishing failures. **Timeline of Events:** * **October 20** – AWS outage began, affecting multiple Pusher clusters leading to increased delays and errors. **October 20, evening UTC** – Pusher clusters began recovery as AWS services were restored. * **October 21, 15:06 UTC** – Internal monitoring detected elevated API errors in AP4; engineers began investigation.  Incident was unrelated to prior AWS outage. * **October 21, 15:09 UTC** – Root cause identified as a failed Redis caching container. * **October 21, 15:27 UTC** – Restoration of Redis connections underway. * **October 21, 15:29 UTC** – Fix implemented; cluster began gradual recovery. * **October 21, 17:39 UTC** – Full stabilization confirmed across AP4 nodes. * **October 21, 17:43 UTC** – Incident marked resolved after sustained recovery. ### **Resolution** To restore full functionality, the engineering team: * Corrected the **Redis container configuration** preventing startup * Restarted and validated cache services across all AP4 nodes * Confirmed API endpoints were fully operational and message publishing resumed * Monitored latency and error metrics to confirm sustained stability ### **Preventative Actions** To reduce recurrence risk and improve detection and response, Pusher is implementing the following: * **Enhanced Redis Monitoring:** Extending monitoring coverage to detect Redis startup and post-init failures. * **Customer Communication Enhancements:** Improving internal escalation and communication processes to ensure faster external updates. ### **Next Steps and Commitment** We recognize the importance of reliable API performance for our customers. Our teams are conducting a full review of caching dependencies and configuration management across all clusters to prevent similar incidents. We sincerely apologize for the disruption caused by this event and appreciate your patience as we worked through a complex multi-day recovery scenario. Pusher remains committed to transparency, reliability, and continuous improvement in service resilience.
PostmortemSource
Oct 20, 20252h 06mSEV 1
US3 cluster - major outageRedis clusters in Pusher's US3 region failed to start after a Docker runtime upgrade, causing latency, 503 errors and a major outage from 18:36 to 20:41 UTC on October 20, 2025. Customers were advised to switch clusters. A configuration fix restored service, and the permanent fix was rolled out to all regions. No customer data was lost.AI-graded · regional · Channels REST API +2
Why this grade
  1. RULES · SEV 1
    Sev 1 because the provider reported data loss or exposure
  2. CLAUDE · SEV 1 · REGIONAL · HIGH CONFIDENCE · BACK AFTER 1H 44M
    Pusher's US3 cluster had a major outage for about two hours; channels, WebSocket and REST APIs failed there, other clusters were unaffected.
  3. Claude Haiku 5.5 · prompt v8 · Oct 23, 2026 · Raw record
8 updates
  1. 18:36 UTC · investigating
    We're seeing an increased latency and a number of 503 errors on us3 cluster. The team is investigating.
  2. 19:01 UTC · investigating
    We are continuing to investigate this issue.
  3. 19:01 UTC · identified
    We are continuing to investigate this issue.
  4. 19:04 UTC · identified
    We are currently experiencing a major outage in US3 cluster. Our engineering team is actively working to restore full functionality as quickly as possible. In the meantime, we recommend customers temporarily switch to an alternative cluster to minimize service disruption.
  5. 19:59 UTC · identified
    Our team has identified the root cause of the issue and implemented a fix. The affected cluster is now in the process of recovering, and performance is gradually returning to normal. We will continue to closely monitor the situation until full recovery is confirmed.
  6. 20:20 UTC · monitoring
    All services are now fully operational. Our team continues to monitor the system closely to ensure ongoing stability and performance.
  7. 20:41 UTC · resolved
    This incident has been resolved.
  8. 20:04 UTC · postmortem
    ## Root Cause Analysis: Redis Cluster Startup Failures – US3 Cluster **Incident Date:** October 20, 2025 **Duration:** 18:36 UTC – 20:41 UTC **Status:** Resolved ## **Summary** On October 20, 2025, customers experienced a significant outage affecting the US3 cluster. The disruption began with increased latency and 503 errors before escalating into full service downtime as Redis clusters in the US3 region failed to start successfully during an infrastructure update. Service was fully restored at 20:41 UTC after engineers identified and resolved the underlying startup issue, confirming stability across all Redis clusters. ## **Impact** Between **18:36 UTC and 20:41 UTC**, customers experienced: * Major outage in the **US3** cluster, impacting message delivery and connection reliability * Elevated error rates and timeouts across dependent APIs * Temporary need for customers to switch to alternate clusters to maintain service continuity No customer data was lost. However, applications relying solely on the affected cluster experienced full downtime for a large portion of the incident. ## **Root Cause** The outage was caused by a failure of Redis clusters to start correctly following an infrastructure update due to a missing configuration flag upon startup. An unexpected upgrade to the Docker runtime running our Redis cluster introduced a breaking change that prevented container startup for certain Redis deployments. When replacement Redis instances in the US3 redis-main cluster were launched, they failed initialization checks and repeatedly restarted, rendering the cluster unavailable. The incompatibility remained undetected until a routine node replacement in the US3 cluster introduced new Redis instances to the cluster. ## **Detection and Response** Monitoring systems first detected increased error rates and latency at **18:36 UTC**, followed by a rise in 503 responses from the affected APIs. **Timeline of events:** * **18:36 UTC** – Increased latency and 503 errors observed in US3 cluster * **19:01 UTC** – Engineering began investigation into Redis startup failures * **19:04 UTC** – Incident declared a major outage; mitigation efforts initiated * **19:59 UTC** – Root cause identified and configuration fix applied * **20:20 UTC** – Services operational; monitoring for recovery stability * **20:41 UTC** – All Redis nodes confirmed healthy; incident resolved ## **Resolution** The engineering team: * Implemented a temporary fix to the Redis environments ensure Redis instances could initialize successfully * Blocked further automated replacements in other clusters until validated * Verified recovery and stability across all Redis clusters After deployment of the fix, Redis instances in the US3 redis-main cluster started correctly and full service was restored. ## **Preventative Actions** To prevent recurrence, the team has: * Rolled out a permanent fix across all Redis clusters used in all regions * Planned a long-term remediation to modernize Redis image packaging for compatibility with current and future Docker releases ## **Next Steps and Commitment** We are conducting a broader review of infrastructure upgrade processes to better detect runtime incompatibilities before they impact production. We apologize for the disruption this incident caused. Ensuring reliability and transparency remains our highest priority, and we continue to strengthen our processes to maintain consistent, predictable service for all Pusher customers.
PostmortemSource
Oct 20, 202513h 49mSEV 2
MT1 cluster - increased latencyIncreased latency on the mt1 cluster slowed realtime and REST API traffic and presence channels; other clusters were not reported affected.AI-graded · some customers · Channels REST API +3
Why this grade
  1. RULES · SEV 1
    Sev 1 because Channels REST API had a partial outage
  2. CLAUDE · SEV 2 · SUBSET · MEDIUM CONFIDENCE
    Increased latency on the mt1 cluster slowed realtime and REST API traffic and presence channels; other clusters were not reported affected.
  3. Claude Haiku 5.5 · prompt v8 · Oct 23, 2026 · Raw record
2 updates
  1. 17:26 UTC · investigating
    Our cloud provider is currently experiencing an incident that's causing increased latency on Pusher Channels main cluster `mt1` . This issue is external to our systems and is not related to our infrastructure. Our team is actively investigating to determine if there are any additional impacts and working to minimize downstream effects while our provider implements a fix.
  2. 07:14 UTC · resolved
    This incident has been resolved.
Source
Oct 20, 202513h 52mSEV 2
Pusher Beams degradationPusher Beams push notification delivery was degraded for an unstated period due to a cloud provider incident; scope not specified.AI-graded · Beams
Why this grade
  1. RULES · SEV 2
    Sev 2 because Beams had degraded performance
  2. CLAUDE · SEV 2 · UNCLEAR · LOW CONFIDENCE
    Pusher Beams push notification delivery was degraded for an unstated period due to a cloud provider incident; scope not specified.
  3. Claude Haiku 5.5 · prompt v8 · Oct 23, 2026 · Raw record
2 updates
  1. 17:21 UTC · investigating
    Our cloud provider is currently experiencing an incident that's affecting Pusher Beams operations. This issue is external to our systems and is not related to our infrastructure. Our team is actively investigating to determine if there are any additional impacts and working to minimize downstream effects while our provider implements a fix.
  2. 07:13 UTC · resolved
    This incident has been resolved.
Source
Oct 20, 20251h 59mSEV 2
Beams - webhook delivery issuesPusher Beams webhook deliveries were disrupted from about 08:20 to 10:18 UTC on 20 October 2025 because of an incident at its external cloud provider. Pusher said the impact was decreasing by 09:34 and that other Beams functions remained operational. The provider did not say how many webhooks failed.AI-graded · Beams
Why this grade
  1. RULES · SEV 2
    Sev 2 because Beams had degraded performance
  2. CLAUDE · SEV 2 · UNCLEAR · MEDIUM CONFIDENCE
    Beams webhook deliveries to customer apps were degraded for about two hours due to an upstream cloud provider incident; other Beams features stayed up.
  3. Claude Haiku 5.5 · prompt v8 · Oct 23, 2026 · Raw record
3 updates
  1. 08:19 UTC · investigating
    Our cloud provider is currently experiencing an incident affecting webhook deliveries in Beams. This issue is external to our infrastructure and is limited to webhooks. Other Beams functionality remains operational. Our team is actively investigating to identify any additional impacts while monitoring the provider's resolution progress.
  2. 09:34 UTC · monitoring
    The impact on our services is decreasing and we have not observed any additional issues with other services. We continue to monitor the situation closely.
  3. 10:18 UTC · resolved
    Our cloud provider is reporting recovery across most affected services. On our side, we haven’t noticed any issues in the past hour, and all services are operating normally. We continue to monitor the situation closely and will provide updates if anything changes.
Source
Oct 20, 20254h 46mSEV 2
MT1 cluster - increased latency and webhook delivery failuresPusher's MT1 cluster saw increased latency and webhook delivery failures on Channels from about 08:10 to 12:57 UTC on 20 October. Pusher attributed the cause to its cloud provider's incident, not its own systems. Services were reported operating normally by 10:17 UTC, and the incident was resolved at 12:57 UTC.AI-graded · one location · Channels Webhooks
Why this grade
  1. RULES · SEV 2
    Sev 2 because Channels Webhooks had degraded performance
  2. CLAUDE · SEV 2 · LOCAL · MEDIUM CONFIDENCE
    Channels on the MT1 cluster had elevated latency and webhook delivery failures for about four hours, caused by an upstream cloud provider incident.
  3. Claude Haiku 5.5 · prompt v8 · Oct 23, 2026 · Raw record
4 updates
  1. 08:10 UTC · investigating
    Our cloud provider is currently experiencing an incident that's causing increased latency and webhook delivery failures. This issue is external to our systems and is not related to our infrastructure. Our team is actively investigating to determine if there are any additional impacts and working to minimize downstream effects while our provider implements a fix.
  2. 09:33 UTC · monitoring
    The impact on our services is decreasing and we have not observed any additional issues with other services. We continue to monitor the situation closely.
  3. 10:17 UTC · monitoring
    Our cloud provider is reporting recovery across most affected services. On our side, we haven’t noticed any issues in the past hour, and all services are operating normally. We continue to monitor the situation closely and will provide updates if anything changes.
  4. 12:57 UTC · resolved
    This incident has been resolved.
Source
Oct 19, 20257h 32mSEV 2
Increased latency - US2 clusterPusher's US2 cluster had elevated latency and some delayed or failed message deliveries from 00:44 to 08:17 UTC on October 19. Subnet IP exhaustion blocked scaling; MT1 and US3 were briefly affected. Manual intervention let US2 scale, restoring normal latency. Pusher plans larger subnets and better IP monitoring.AI-graded · regional · Channels WebSocket client API +1
Why this grade
  1. RULES · SEV 2
    Sev 2 because Channels WebSocket client API had degraded performance
  2. CLAUDE · SEV 2 · REGIONAL · MEDIUM CONFIDENCE
    Realtime messaging on the US2 cluster had elevated latency and some failed deliveries for about 7.5 hours; other clusters were briefly affected.
  3. Claude Haiku 5.5 · prompt v8 · Oct 23, 2026 · Raw record
5 updates
  1. 00:44 UTC · investigating
    Increased latency and degraded performance on clusters main, us2 and us3.
  2. 03:11 UTC · identified
    The issue has been identified and we are applying mitigations. We are seeing improved latency in main and us3 clusters. us2 still has elevated latency.
  3. 04:03 UTC · identified
    We have scaled all three clusters out to handle the increased traffic. We anticipate the latency to slowly improve.
  4. 08:17 UTC · resolved
    Latency has remained stable over the past three hours. Our investigation identified multiple contributing factors to the earlier latency increase, including network saturation and capacity limits at our cloud providers affecting the US2 cluster. The US3 cluster issue was resolved quickly through autoscaling, while the US2 cluster experienced scaling delays that required manual intervention. We are implementing corrective measures to prevent recurrence and improve system resilience.
  5. 14:16 UTC · postmortem
    ## **Root Cause Analysis: Increased Latency and Message Delivery Failures – US2 Cluster** **Incident Date:** October 19, 2025 **Duration:** 00:44 UTC – 08:17 UTC **Status:** Resolved ### **Summary** On October 19, 2025, customers using Pusher experienced increased latency and message delivery failures. These issues primarily affected the US2 cluster, with intermittent impact also observed in the MT1 and US3 clusters.  The incident resulted in delayed or undelivered messages for many applications. Latency stabilized at 08:17 UTC after mitigation actions were completed. ### **Impact** Between 00:44 UTC and 08:17 UTC, multiple customers experienced: * **Delayed or failed message delivery** across affected clusters * **Degraded performance** in connection establishment and publishing The most significant and prolonged impact occurred in the **US2 cluster**, while **MT1** and **US3** clusters saw elevated latency for a shorter period before stabilizing. ### **Root Cause** The primary cause of the incident was IP address saturation within the subnet assigned to the public Pusher clusters. When traffic levels increased, the **US2 cluster** was unable to scale out further because the available IP addresses in its subnet were fully utilized. This IP scaling limitation prevented the creation of additional instances needed to handle the load. Secondary factors included temporary **network saturation** and **capacity limits** at our cloud provider, which amplified the latency in the early stages of the incident. ### **Detection and Response** The issue was first detected through a combination of **customer reports** and **internal monitoring alerts** showing elevated response times and connection errors. The timeline of actions was as follows: * **00:44 UTC** – Monitoring alerted the team to increased latency across MT1, US2, and US3 clusters. * **03:11 UTC** – Engineers identified subnet capacity as a contributing factor; mitigations began. * **04:03 UTC** – All clusters were scaled out to distribute traffic; latency began to improve in MT1 and US3 clusters. * **08:17 UTC** – Manual intervention allowed US2 to scale successfully, restoring normal latency. ### **Resolution** To restore service, the engineering team: * Scaled out **MT1** and **US3** clusters to handle increased traffic loads * Monitored all clusters to confirm sustained stability Once additional capacity was provisioned and high loads normalized, latency levels returned to normal and remained stable. ### **Preventative Actions** To prevent recurrence, Pusher has initiated the following actions: * **Rate Limits:** We will re-evaluate how rate limits are implemented to better mitigate content from neighboring customers on the shared clusters. * **Subnet Expansion:** Re-evaluating and increasing the size of subnets assigned to shared clusters to ensure sufficient IP availability for future scaling events. * **Load Balancer Enhancements:** We will implement load balance sharding in order to better distribute connections. * **Capacity Planning Improvements:** Enhancing internal monitoring and alerting for subnet and IP utilization thresholds. ### **Next Steps and Commitment** We recognize that message latency and delivery reliability are critical to our customers’ applications. Our team is continuing a full review of cluster capacity management and provider configuration to improve resilience under high traffic conditions. We apologize for the disruption this incident caused and appreciate your patience while we worked to resolve it. Ensuring reliability and transparency remains our highest priority.
PostmortemSource
Sep 19, 202534h 39mSEV 3
Higher latency on our AP1 cluster for some customersHigher latency on Pusher's AP1 cluster for some customers across WebSocket, presence and webhook features; duration of impact unclear.AI-graded · regional · Channels WebSocket client API +2
Why this grade
  1. RULES · SEV 2
    Sev 2 because Channels WebSocket client API had degraded performance
  2. CLAUDE · SEV 3 · REGIONAL · MEDIUM CONFIDENCE
    Higher latency on Pusher's AP1 cluster for some customers across WebSocket, presence and webhook features; duration of impact unclear.
  3. Claude Haiku 5.5 · prompt v8 · Oct 23, 2026 · Raw record
3 updates
  1. 21:15 UTC · identified
    The issue has been identified and a fix is being implemented.
  2. 09:57 UTC · monitoring
    A fix has been implemented and we are monitoring the results.
  3. 07:54 UTC · resolved
    This incident has been resolved.
Source

Peers, 90 days

Compare
MailerSendGrade A+100.00% up0 incidentsMTTR –LoopsGrade A+100.00% up1 incidentMTTR 1h 34mKindeGrade A+99.99% up2 incidentsMTTR 1h 12mPaddleGrade A+100.00% up3 incidentsMTTR 47mCloudinaryGrade A99.97% up5 incidentsMTTR 1h 47mAblyGrade A99.97% up7 incidentsMTTR 7mMailgunGrade A99.96% up9 incidentsMTTR 42mPusherGrade A99.96% up2 incidentsMTTR 3h 45mResendGrade B99.86% up25 incidentsMTTR 24mInngestGrade B99.75% up14 incidentsMTTR 43mMapboxGrade C99.91% up2 incidentsMTTR 12h 38mClerkGrade C99.88% up10 incidentsMTTR 3h 26mWorkOSGrade C99.43% up21 incidentsMTTR 1h 05mStytchGrade C99.79% up7 incidentsMTTR 57mPlaidGrade F98.14% up18 incidentsMTTR 3h 38mTwilioGrade F96.38% up56 incidentsMTTR 7h 26m

README badge

Pusher's live grade, for your README.

Pusher grade badge
[![pusher on downagain.dev](https://downagain.dev/badge/pusher.svg)](https://downagain.dev/p/pusher)