Ably vs Pusher deep dive: reliability, failover, and global infrastructure compared

• Architecture: Ably runs a peer-to-peer multi-region mesh where each region operates independently and communicates directly with other regions. Pusher assigns each application to a single cluster at creation; that cluster cannot be changed, and there is no built-in failover between clusters.

• Failover: Ably automatically reroutes traffic via DNS and provides SDK-level failover to up to five globally-distributed endpoints when a region experiences issues. Pusher has no built-in inter-cluster failover.

• Latency: Ably delivers a 6.5ms message delivery latency via latency-based DNS routing to the nearest of 700+ PoPs. Pusher's latency depends on the distance between the user and the chosen cluster, which is fixed at app creation and cannot be changed.

• Message survivability: Ably achieves 99.999999% (8x9s) message survivability through multi-region replication. Pusher does not replicate data between clusters and does not store messages after delivery. If a cluster fails during transit, those messages are lost.

The reliability difference between the two platforms traces back to one architectural decision: Pusher assigns each application to a single datacenter; Ably runs a peer-to-peer multi-region mesh where every region is autonomous and interconnected.

When you create an application on Pusher, you choose a cluster - a single AWS datacenter in a fixed location. All traffic for that application is then handled by that cluster. Changing region means creating a new app and migrating your users to it. For companies operating at a global scale, this can mean creating and managing multiple apps, across multiple regions.

If your chosen cluster goes down, Pusher also has no built-in mechanism to automatically redistribute your traffic to a healthy one. A custom failover process is possible, but it is entirely the developer's responsibility to build, test, and maintain.

Ably runs across 11 core regions and 700+ PoPs, with each region operating independently and communicating peer-to-peer rather than through a central hub. Clients connect to the nearest PoP via latency-based DNS, and messages flow directly between regions over the AWS backbone. Each region replicates its state continuously with the others, so a regional failure does not create a message gap or force clients to reconnect from scratch.

When a Pusher cluster goes down, every application on it is affected — and because there is no automatic mechanism to redistribute traffic to a healthy cluster, the outage persists until Pusher resolves it or the developer implements a manual workaround.

On September 8, 2024, Pusher's US2 cluster experienced a major outage. The majority of clients were unable to connect via WebSocket for approximately five hours. This cluster remains a recurring source of incidents. During the most recent outage, on February 15, 2026, IsDown logged an “Increased error rate on the US2 cluster”.

When a region experiences issues, Ably responds at two levels:

1. Infrastructure: DNS changes redirect new connections to the nearest healthy region.

2. Client: Ably's SDK automatically fails over to up to five globally-distributed endpoints - no application code required.

Pre-existing connections are handled separately. Because Ably's frontend nodes are stateless, active sessions are not interrupted by the failover process.

In October 2024, AWS experienced a significant disruption to its us-east-1 region. Ably's post-incident review confirmed that existing infrastructure continued to serve traffic without errors throughout, while DNS changes redirected new connections to us-east-2 at midday UTC.

The cluster-selection model has two practical consequences for production applications: latency for users far from the chosen cluster, and survivability if that cluster fails.

Pusher's latency depends on the distance between the end user and the cluster chosen at app creation. A Pusher application on the mt1 (US East) cluster serves US East users well, but users in Asia-Pacific, South America, or Europe connect to a datacenter that may be thousands of miles away, with no routing optimization to close that gap. Because the cluster cannot be changed after app creation, teams that underestimated their geographic distribution at launch cannot correct this without a full migration to a new app.

Ably delivers a 6.5ms message delivery latency via latency-based DNS routing to the nearest of its 700+ PoPs. Round-trip latency is under 30ms at the 99th percentile within a datacenter and under 99ms mean across all PoPs.

SpringboardVR migrated from Pusher to Ably because of latency issues affecting globally distributed users, and reported average latency reduced by over 100% after migrating.

Message survivability is the probability that a published message is delivered to its intended recipients, accounting for infrastructure failures, regional disruptions, and network interruptions during transit.

Pusher's per-cluster architecture has no cross-cluster replication and no persistent message store. Messages exist in a single cluster's memory during transit. If that cluster fails, those messages are lost.

Ably achieves 99.999999% (8x9s) message survivability through continuous multi-region replication. Before returning the publish acknowledgment, Ably replicates the message across multiple regions. A regional failure after replication results in no message loss.

The sections above explain the mechanisms behind each dimension. The table below summarizes the outcome across each one.

For how these architectural choices affect message ordering and delivery guarantees, see the delivery guarantees deep dive. 

For a side-by-side feature table covering pricing, security, and compliance, see the Ably vs Pusher feature comparison.

Pusher's single-cluster model works well for applications with a geographically concentrated user base, provided teams are prepared to configure fallback transports and implement their own failover process to redirect traffic in the event of a cluster outage. 

Ably's multi-region architecture absorbs the infrastructure events that would require engineering intervention on Pusher. The tradeoff is a higher initial investment to understand and configure the platform correctly. The benefit is availability that doesn't depend on your team responding to an incident.

For AI applications, infrastructure reliability and delivery guarantees compound. Session continuity depends on both - a platform that absorbs failures without dropping connections, and one that guarantees ordered, exactly-once delivery.

Building on infrastructure that handles failures automatically means reliability becomes a property of the platform rather than a responsibility of your team. If that’s the foundation you want, start building on Ably for free or talk to an engineer about your reliability requirements.

No. Pusher’s own documentation states that Channels has no built-in failover between clusters. A manual failover process is possible, but it is a developer-implemented workaround rather than a platform capability. It requires your server to return credentials for an alternative cluster and existing clients to reconnect. Ably's failover is automatic at both the DNS and SDK level, requiring no application code to trigger.

All applications on that cluster are affected. Because each Pusher application is bound to a single cluster, a cluster-level outage has no automatic escape route. The September 2024 US2 outage illustrates this. The majority of clients were unable to connect via WebSocket for approximately five hours.

No. The cluster is chosen at app creation and cannot be edited. Migrating an existing application to a different cluster requires creating a new Pusher application in the target cluster and migrating all users to it.

At the infrastructure level, Ably makes DNS changes to redirect new connections away from the affected region to the nearest healthy one. At the client level, Ably’s SDK automatically fails over to up to five globally-distributed endpoints without requiring any application code. Pre-existing connections continue to be served by the infrastructure already in place in the affected region, independent of where new connections are being routed.

Message survivability is the probability that a published message is delivered despite infrastructure failures during transit. Ably achieves 99.999999% (8x9s) message survivability through continuous multi-region replication. Before returning the publish acknowledgment, Ably replicates the message across multiple regions. A regional failure after replication results in no message loss. Pusher does not replicate data between clusters. Messages exist in a single cluster's memory during transit. If a cluster fails during that window, those messages are not delivered.