Ably Pricing in 2026: Why Your Bill Is Deliveries, Not Sends

Quick answer (2026): Ably's realtime meter has three parts: messages at $2.50 per million, connection minutes at $1.00 per million, and channel minutes at $1.00 per million, on top of a Free tier ($0), Standard ($29/mo), or Pro ($399/mo) base. Ably sells that meter under two selectable billing models: pay per minute (the consumption meter above) or pay per MAU at $0.05 per monthly active user, where each MAU carries 20,000 messages and 2,000 connection minutes. The two are priced at par, so MAU buys predictability, not a discount. The same three meters now bill all six Ably products (Pub/Sub, Chat, AI Transport, LiveObjects, Spaces, LiveSync), so the pricing model does not change with the product you adopt. The number that wrecks most estimates is that a "message" is counted per delivery, not per send: publish once to 100 subscribers and the meter records 101 messages. For persistent apps the bigger surprise is the minutes meters, which quietly bill every connection and every channel for as long as they stay open. Volume discounts can drop the message rate to $0.50 per million and the minute rates to $0.20 per million, but the thresholds are not published. Below is the arithmetic, three worked 30-day bills, the best-case floor, and the one architectural lever that cut a sample bill by 48.8%.

Updated August 21, 2026: re-verified all three consumption meters and every plan price against Ably's live pricing page (unchanged), and added full coverage of Ably's second billing model, pay per MAU, including the per-MAU allowances, the at-par arithmetic, and where the crossover actually sits. Earlier August 8, 2026 pass added the 2026 platform changes (six products now share one meter, including the new AI Transport product), a worked volume-discount floor, and how Ably's meter compares to PubNub's MAU model and Supabase Realtime.

Ably pricing plans in 2026, at a glance

Ably has four base plans. The base fee buys capacity ceilings and support; all four carry the same per-unit usage rates on top.

Does Ably have a free tier? Yes. The Free plan is $0 with no credit card and includes 6 million messages a month plus 200 concurrent connections and 200 channels, with a 500-messages-per-second rate cap. You start paying only when you exceed those allowances or need a higher plan's ceilings.

What changed in Ably pricing for 2026

The rates did not move; the product surface did. Ably is no longer a single pub/sub service with a pricing page bolted on. As of 2026 it sells six products that all sit on the same base plans and the same three usage meters (pricing, 2026):

The practical takeaway: adopting Ably Chat or the new AI Transport does not add a separate per-product line item. Every one of them resolves back to messages, connection minutes, and channel minutes. So the estimate you build below is the estimate for whichever product you pick. That is unusual. Most realtime vendors price chat, sync, and pub/sub as distinct SKUs; Ably folds them into one meter, which is simpler to reason about but means the same per-delivery and per-minute traps apply everywhere.

The three meters, in plain numbers

Ably bills usage across three dimensions on top of the base plan. One metric per row, at 2026 list rates:

That looks tame. Two of those meters are where real bills come from, and neither is the one people budget for.

The one word that changes the bill: deliveries

Ably counts a message every time one is delivered, not every time one is sent. Their own documentation (message counting, 2026) puts it plainly: if a user publishes a message and 10 users receive it, that counts as 11 messages. History reads and integration egress count too.

So your real message volume is not "messages sent." It is:

billable messages = publishes x (1 + average subscribers per channel)

That average-subscribers term is a multiplier, and it is the whole ballgame. The same one million publishes cost wildly different amounts depending on how many people are listening.

Same publish volume. A 500x spread on the bill. If you estimated Ably by counting the messages your servers emit, you undercounted by your fan-out factor.

The minutes meters: what "always on" actually costs

A 30-day month holds 43,200 minutes (30 x 24 x 60). A connection that stays open the whole month burns 43,200 connection minutes. At $1.00 per million:

• One always-on connection: 43,200 minutes = $0.0432 per month.
• One always-on channel: 43,200 minutes = $0.0432 per month.

Fractions of a cent. That is exactly why they get ignored, and exactly why they surprise people at scale. Ten thousand always-on connections is 432 million connection minutes, or $432 a month, before a single message is sent. One channel per device across 20,000 devices is another $864 a month in channel minutes alone.

Three worked 30-day bills (2026 list rates)

These use published per-unit rates applied to usage. They are the usage meter only; your plan's base fee and included allowance sit on top.

Cohort A: support-chat widget. 300 average concurrent connections, 300 channels, 2M publishes at fan-out 2 (6M messages).

Messages are 37% of usage; the minutes meters are 63%. Note the 6M messages sit right at the Free tier allowance, so on a paid plan this app is mostly paying for connected time, not chatter.

Cohort B: live broadcast (scores, auctions). 5,000 average concurrent viewers, 50 match channels, 500k publishes at fan-out 100 (50.5M messages).

Here the score updates are cheap. The 5,000 people watching are 63% of the bill. Broadcast apps pay for the audience sitting connected, not the events.

Cohort C: IoT / presence. 20,000 devices, one channel each, 5M telemetry publishes at fan-out 1 (10M messages).

Messages are 1.4% of this bill. The minutes meters are 98.6%. The killer is one-channel-per-device.

How low can the bill go? The volume-discount floor

Ably advertises the message rate falling to $0.50 per million and both minute rates to $0.20 per million "with volume discount," but it does not publish the thresholds where those kick in. They are committed-use terms you negotiate, not a public tier table. So treat the floor as a best case, not a plan you can self-select.

The floor matters because it is a 5x cut on every meter (messages 2.50 to 0.50, minutes 1.00 to 0.20). Applied to Cohort C, the most meter-heavy of the three:

That is 80% off the same usage. The lesson is not "wait for the discount." It is that if your bill is already in four figures a month, the negotiated floor is worth a sales conversation before you re-architect, because a committed-use rate can do most of what channel-sharing does without touching your code. Below roughly a few hundred dollars a month you will pay list, so the architectural levers below are the only ones you control.

The one lever: share channels

Cohort C spends $864/mo on channel minutes because it opens 20,000 channels, one per device. If device isolation allows multiplexing (namespacing many devices onto shared channels with client-side filtering), 20,000 channels become 200 channels of 100 devices each:

• Channel minutes: 864M drops to 8.64M, from $864.00 to $8.64.
• New usage total: $897.64, down from $1,753.00.

One architectural change. A 48.8% cut to the whole bill, with no change to how many messages move. For fan-out apps the equivalent lever is coalescing publishes: a live-cursor feed throttled from 30 updates per second to 10 sheds two-thirds of its billable deliveries, because message cost scales with publishes times audience.

Pay per minute or pay per MAU: where the crossover is

Ably runs two selectable billing models, not one. The meter this teardown has priced so far is pay per minute, the consumption model. The alternative is pay per MAU (pricing, MAU view, 2026), billed on top of the same Free, Standard, Pro, and Enterprise packages:

Ably defines an MAU narrowly and literally: "a unique user who connects to Ably at least once during the month." One connection, all month, is a whole billable user.

The at-par finding: MAU is a variance swap, not a discount

Price the allowance one MAU grants, at consumption list rates:

• 20,000 messages at $2.50 per million = $0.050
• 2,000 connection minutes at $1.00 per million = $0.002
• Total list value of one MAU's allowance: $0.052

You pay $0.05 for $0.052 of usage. That is par, within 4%. Now run it at the volume floor: 20,000 messages at $0.50 per million is exactly $0.010, against a discounted MAU price of $0.01. Par again, at the other end of the discount curve.

That is the finding. Ably has not priced MAU as a bulk discount on the meter; it has priced it at the meter's own value. What you buy is a fixed, forecastable per-user line item instead of a per-delivery meter that moves with your fan-out. It is a variance swap. If you switch models hoping for a cheaper bill at the same usage, you will not get one.

The break-even, per active user

Because the MAU price tracks the allowance, the crossover is simply whether your average user actually consumes what the allowance grants. Assuming connection time stays inside the 2,000-minute allowance (add $0.001 per extra 1,000 connection minutes):

Remember these are deliveries, not sends, so the delivery multiplier from earlier is what carries a user toward the allowance. A user reading a 25-subscriber channel accumulates billable messages 26 times faster than the publish count suggests.

The wide-and-shallow trap

The MAU definition is where the real money goes wrong. Because anyone who connects once counts as a full MAU, an audience that is broad and light is the worst possible fit. Take a public live scoreboard: 100,000 monthly visitors, each connecting once for about 10 minutes and receiving roughly 100 updates.

That is a 192x difference on identical traffic, and it is the single most expensive model-selection mistake available on this pricing page. Public dashboards, status pages, scoreboards, and marketing-site presence widgets all have this shape.

The always-on trap, in the other direction

The 2,000 connection minutes per MAU is worth reading as a duration: 2,000 minutes is 33.3 hours per user per month. A 30-day month holds 43,200 minutes, so a client that stays connected continuously burns 21.6x its per-MAU connection allowance. Per-MAU pricing is built for session-based human usage, not for persistent devices or IoT fleets.

One more gap worth confirming before you switch: Ably's per-MAU table lists allowances for messages and connection minutes only. It shows no channel-minute allowance. Given that channel minutes were 49% of Cohort C's bill above, ask Ably directly how channel minutes are treated under the MAU model if your design opens a channel per entity. Ably also does not publish an overage rate for exceeding the per-MAU allowances, so treat 20,000 messages per user as the model's design envelope rather than a soft limit, and confirm the treatment above it.

The short version. Choose per-minute if your audience is broad, light, bursty, or channel-heavy. Choose per-MAU if you have a steady, contained user base whose average member genuinely works the allowance, and you value a predictable per-seat number you can put in a spreadsheet. Ably's own guidance agrees and is worth quoting: "If your app has short, high-volume bursts, Pay Per Minute may be better. For steady user bases, MAU is often more cost-effective."

Ably vs Pusher vs PubNub vs Supabase vs self-host

Ably is not the only meter shape, and the shape matters more than the sticker price.

• Pusher Channels (pricing, 2026) meters on peak concurrent connections plus messages per day, with no minutes meter at all. An app with many quiet-but-connected clients can be cheaper on Pusher (no per-minute bleed); a chatty app that blows past daily message caps can be cheaper on Ably. We broke Pusher's meter down in the Pusher pricing teardown.
• PubNub (pricing, 2026) bills a single metric, Monthly Active Users, starting at $98/mo for 1,000 MAU (free tier: 200 MAU or 1M transactions). That flips the estimation math entirely: connection minutes and channels are irrelevant, and you model your unique-user count instead. A many-connections-per-user or always-on-fleet app can be far cheaper on PubNub's MAU model; a low-user, high-message app can be cheaper on Ably. Note that Ably now sells its own per-MAU option too, but the two are not the same shape: PubNub's MAU is a single all-in metric, whereas Ably's MAU carries capped per-user allowances (20,000 messages, 2,000 connection minutes) on top of a package fee, as priced out above.
• Supabase Realtime (pricing, 2026) is bundled into Supabase's platform plans (Free, then Pro at $25/mo) rather than sold as a standalone metered realtime product. If you already run Postgres on Supabase, basic broadcast, presence, and Postgres-change streams are effectively included, which makes it the cheapest option for apps whose realtime needs are modest and database-adjacent.
• Self-host with an open-source, Pusher-protocol-compatible server like Soketi or Centrifugo removes per-message and per-minute cost entirely. You trade it for a VM (roughly $20 to $80/mo) plus the reconnection, presence, and scaling work you now own. That trade is the subject of our build vs buy at scale piece.

When Ably is worth it, and when it is not

Honest read for 2026:

• Worth it when you would otherwise build global edge presence, guaranteed ordering, reconnection, and protocol adapters yourself, and when your traffic is spiky. The minutes meter is fair for bursty apps: you pay only for connected time, not for provisioned capacity. The unified meter across Chat, AI Transport, and Spaces also means you can add product surface without re-modeling your bill.
• Not worth it when you are a high-fan-out broadcaster at scale (the message meter compounds by your audience) or when your design opens one channel per entity across tens of thousands of entities (the minutes meters compound by count). At that point PubNub's MAU model, a self-hosted server, or a plain SSE/CDN fan-out is often several times cheaper.

Price the meter you will actually hit. For most realtime apps that is not the message count on your dashboard; it is deliveries times audience, plus every minute you leave a connection open.