---
source_url: https://www.pubnub.com/docs/architecture/latency
title: PubNub latency and overhead figures
updated_at: 2026-10-28T09:58:30.000Z
---

# PubNub latency and overhead figures

> For AI agents: documentation index at https://www.pubnub.com/llms-full.txt

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](#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](#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](#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](#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](https://www.pubnub.com/docs/architecture/how-pubnub-works.md#where-your-clients-connect) explains how clients reach their nearest PoP.

The message path runs from the publisher over the network to ingest in the nearest PubNub region. Inside the region, the message goes through ingest, route and replicate, and ready for delivery. It then crosses the network to the subscriber. Ingest returns an acknowledgment (ACK) to the publisher.

```mermaid
flowchart LR
    Publisher -->|network| Ingest
    Ingest -.->|ACK| Publisher
    subgraph Region["PubNub region (nearest PoP)"]
        Ingest --> Route["Route and replicate"] --> Ready["Ready for delivery"]
    end
    Ready -->|network| Subscriber
```

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).** Values are the same in both directions. The diagonal shows same-region latency.

* US West (sjc) to US East (iad): 29.4 ms
* US West (sjc) to Frankfurt (fra): 75.6 ms
* US West (sjc) to Mumbai (bom): 118 ms
* US West (sjc) to Tokyo (hnd): 53.8 ms
* US East (iad) to Frankfurt (fra): 45.3 ms
* US East (iad) to Mumbai (bom): 100 ms
* US East (iad) to Tokyo (hnd): 74 ms
* Frankfurt (fra) to Mumbai (bom): 63.5 ms
* Frankfurt (fra) to Tokyo (hnd): 112.5 ms
* Mumbai (bom) to Tokyo (hnd): 64.5 ms
* Any region to itself (same region): < 0.5 ms

| From \ To | US West (sjc) | US East (iad) | Frankfurt (fra) | Mumbai (bom) | Tokyo (hnd) |
| --- | --- | --- | --- | --- | --- |
| US West (sjc) | < 0.5 ms (same region) | 29.4 ms | 75.6 ms | 118 ms | 53.8 ms |
| US East (iad) | 29.4 ms | < 0.5 ms (same region) | 45.3 ms | 100 ms | 74 ms |
| Frankfurt (fra) | 75.6 ms | 45.3 ms | < 0.5 ms (same region) | 63.5 ms | 112.5 ms |
| Mumbai (bom) | 118 ms | 100 ms | 63.5 ms | < 0.5 ms (same region) | 64.5 ms |
| Tokyo (hnd) | 53.8 ms | 74 ms | 112.5 ms | 64.5 ms | < 0.5 ms (same region) |

## 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](#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](#latency-between-pubnub-regions), plus each user's last-mile network. |
| Waiting on a publish to return | [Publish-processing](#publish-processing), plus the round trip to the nearest PoP. |
| Comparing PubNub with another provider | [End-to-end delivery](#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](https://www.pubnub.com/docs/architecture/data-transport-and-delivery.md) 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.

```js
// 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](https://www.pubnub.com/docs/data-storage/message-history/overview.md). [Data transport and delivery](https://www.pubnub.com/docs/architecture/data-transport-and-delivery.md) 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](https://www.pubnub.com/docs/architecture/how-pubnub-works.md). Routing, replication, and fault tolerance behind these figures.
* [Data transport and delivery](https://www.pubnub.com/docs/architecture/data-transport-and-delivery.md). The subscribe loop and delivery semantics.
* [Publish](https://www.pubnub.com/docs/pub-sub/publish/overview.md). The publish response and timetokens.

Last updated at: 2026-10-28T09:58:30.000Z