PubNub latency and overhead figures

PubNub reports three figures for message delivery on its real-time messaging network: in-region overhead, publish-processing, and end-to-end delivery. Each one measures a different stretch of a message's journey, so the figures aren't interchangeable. This page defines each figure, shows where it's measured, and explains which question each one answers.

The three latency figures

For any latency number, ask two questions. Between which two points is it measured, and does it include network transit? The table answers both for each figure.

Figure	Value	Measured between	Network transit
In-region overhead	< 0.5 ms	Ingestion of a message until it's ready for delivery to subscribers, inside one region. This is the time PubNub itself adds.	Excluded
Publish-processing	≈ 0.5 ms, same region	A publish request reaching PubNub until PubNub accepts and acknowledges it. This is not delivery to subscribers.	Excluded
End-to-end delivery	≈ 57.79 ms average, ≈ 64.97 ms cross-zone	Publisher to subscriber, wire to wire.	Included

The figures can look contradictory until you compare what they cover. The in-region overhead of less than 0.5 ms is the time PubNub adds inside one region. The end-to-end average of about 57.79 ms is the full journey between two devices, including the distance between them. A comparison is only valid between figures that measure the same stretch.

In-region overhead

Inside one region, PubNub adds less than 0.5 ms to a message between ingestion and the moment it's ready for delivery to subscribers, not counting network transit, as measured by PubNub's same-region latency monitoring.

Use in-region overhead to judge the part of delivery that PubNub controls, and to compare messaging providers on what they add themselves. For users in the same region, add each user's own network hop to the nearest PoP.

Publish-processing

Publish-processing latency, the time PubNub takes to accept and acknowledge a publish request, is about 0.5 ms within the same region.

Publish-processing answers how long a publish call takes to return. It doesn't tell you when subscribers receive the message. The call your application makes also includes the round trip to the nearest PoP.

End-to-end delivery

Measured end-to-end delivery latency, from publisher to subscriber wire to wire and including network transit, averages approximately 57.79 ms, or approximately 64.97 ms across zones.

End-to-end delivery is the closest of the three figures to what users experience. The average and the cross-zone figure differ mainly because of the distance between publisher and subscriber. Latency between PubNub regions shows what a given region pair adds.

Where each latency figure is measured

A message travels from the publisher over the network to the nearest PoP. A PoP is a PubNub message-routing region, not a CDN edge node. That PoP accepts the message, prepares it for delivery, and replicates it to the PoPs that serve its subscribers. The diagram marks the stretch each figure covers. How PubNub works explains how clients reach their nearest PoP.

The diagram is simplified. When the subscriber is served by another PoP, replication to that PoP sits inside the end-to-end stretch.

How PubNub measures latency

PubNub derives its latency figures from continuous production telemetry collected by its latency monitoring, not from synthetic lab benchmarks or loopback tests.

Latency between PubNub regions

Across regions, latency is dominated by physical distance. The table shows measured one-way latency between selected PubNub regions.

One-way latency between PubNub regions (ms). Hover over, focus, or tap a cell for the exact value.

From \ To	US West sjc	US East iad	Frankfurt fra	Mumbai bom	Tokyo hnd
US West sjc	< 0.5 ms	~29 ms	~76 ms	~118 ms	~54 ms
US East iad	~29 ms	< 0.5 ms	~45 ms	~100 ms	~74 ms
Frankfurt fra	~76 ms	~45 ms	< 0.5 ms	~64 ms	~113 ms
Mumbai bom	~118 ms	~100 ms	~64 ms	< 0.5 ms	~65 ms
Tokyo hnd	~54 ms	~74 ms	~113 ms	~65 ms	< 0.5 ms

• < 0.5 ms (same region)
• < 50 ms
• 50–79 ms
• 80–109 ms
• ≥ 110 ms

Which latency figure answers which question

If the question concerns users who are	The figure that answers it
In the same region as each other	In-region overhead, plus each user's own network hop to the nearest PoP.
On different continents	The region pair in Latency between PubNub regions, plus each user's last-mile network.
Waiting on a publish to return	Publish-processing, plus the round trip to the nearest PoP.
Comparing PubNub with another provider	End-to-end delivery. The other provider's figure must also run from publisher to subscriber and include network transit.

How timetokens expose latency in your application

PubNub assigns every published message a server-side timetoken: a monotonically increasing 17-digit value precise to 100 nanoseconds (10⁻⁷ s), the number of 100-nanosecond intervals since the Unix epoch.

A timetoken therefore records when PubNub accepted a publish. Comparing it with the subscriber's clock gives the time from acceptance to receipt. The subscriber's clock can differ from PubNub's, so an application first estimates the offset. It compares its own clock with PubNub server time from the time() call. The example shows this in JavaScript.

// Estimate the subscriber's clock offset from PubNub server time
const t0 = Date.now();
const { timetoken } = await pubnub.time();
const offsetMs = Number(timetoken) / 1e4 - (t0 + Date.now()) / 2;


pubnub.addListener({
  message: (event) => {
    const acceptedMs = Number(event.timetoken) / 1e4;
    const latencyMs = Date.now() + offsetMs - acceptedMs;
    console.log(`accept → receive: ${latencyMs.toFixed(1)} ms`);
  },
});

The example measures from the moment PubNub accepts the publish, not from the publisher, so it excludes the publisher's network hop. To measure full end-to-end delivery, also put a publisher-side timestamp in the message payload.

What PubNub does and doesn't guarantee

PubNub offers a 99.999% uptime SLA, which allows about 5 minutes of downtime per year.

PubNub reports latency as observed and does not guarantee it contractually, because the last-mile network is outside any provider's control.

Live delivery to subscribers is at-most-once by default. On a stable connection, a subscriber receives each message at most once. After a reconnect, a replayed message can arrive again with the same timetoken. A subscriber can also miss messages if its buffer overflows or if it's disconnected when someone publishes a message.

An application that needs to recover missed messages builds that itself. It stores the last timetoken it processed and replays missed messages with Message Persistence. Data transport and delivery explains the details.

PubNub delivers real-time messages over HTTP long polling on ordinary HTTPS connections. PubNub doesn't use WebSocket.

Next steps

• How PubNub works. Routing, replication, and fault tolerance behind these figures.
• Data transport and delivery. The subscribe loop and delivery semantics.
• Publish. The publish response and timetokens.