---
title: "Latency you can actually feel"
summary: "For messages, the network is rarely the slow part: queues, carriers and handsets dominate, and most of it is chosen at purchase. For live calls, a few hundred milliseconds decides whether a conversation feels natural."
canonical: https://cpaas.co/en/learn/latency-you-can-actually-feel
kind: article
depth: applied
origin: original
published: 2026-08-10T16:26:18.899Z
updated: 2026-10-14T16:26:19.505Z
topics: ["Architecture", "Messaging", "Analytics"]
language: en
---
# Latency you can actually feel

A customer taps "send code", waits, taps again, and gives up before either code arrives. Your API dashboard says the provider answered in 120 milliseconds. Both are true: the part you measure is the smallest part of the wait. Latency in communications comes in two very different kinds — seconds for a message to reach a phone, milliseconds for a live call to feel natural — and in both, the time people feel is mostly decided by routes and design, not by your code. This piece covers where the time goes, what to measure, and how to design for the slow case.

> **Interactive figure — latency-race.** Run it. Then notice that the differences between channels are smaller than the difference between a well-run send path and a badly-run one.
> Available at https://cpaas.co/en/learn/latency-you-can-actually-feel

## Two kinds of latency

| | Messages (SMS, WhatsApp, RCS) | Live media (voice and video calls) |
|---|---|---|
| Unit | Seconds | Milliseconds |
| What people notice | Waiting for a code or alert | Talking over each other, awkward pauses |
| Main causes | Queues, carrier handling, handset state | Distance, network jitter and loss, relay servers |
| Main fixes | Better routes, sending early, fallback design | Nearby media servers, good networks, adaptive codecs |

## Where the time goes for a message

For a one-time code — the most latency-sensitive message most businesses send — the budget looks nothing like people expect:

```diagram:bars
# An illustrative one-time code, from button press to handset, in milliseconds
Your application | 40 | Generating the code, storing it, calling the send function.
Provider API | 120 | Accepting the request and queueing it. Usually the only leg with a published SLA.
Aggregator hop | 300 | Where a partner route rather than a direct one shows up as time.
Carrier queue | 1400 | Not yours, not your provider's, and highly variable by market and hour.
Handset delivery | 900 | Radio conditions, device state, whether the phone is asleep.
> In this example about 6% of the total is code you can optimise. The rest is chosen at procurement, not at runtime.
```

The API call — the only segment many teams instrument — is often the smallest term. Under load, or when a route is congested, queueing dominates everything else, and the same code can take two seconds in one country and twenty in another.

## What actually helps

1. **Measure end to end.** A timestamp when you decided to send, and one when the delivery receipt arrives. That is the number the customer experiences.
2. **Watch the tail, not the average.** Nobody experiences the mean. The 95th and 99th percentiles are what a support team hears about; a two-second average routinely hides a tail in the tens of seconds.
3. **Split by country and hour.** Latency problems are local. A global number hides the market that is broken on Tuesday afternoons.
4. **Choose the route.** A direct connection to operators in-market typically beats any optimisation above it. This is a purchasing decision that looks like an engineering one.
5. **Do the slow work early.** Consent state, template approval and route choice should be ready before the send; the send path should not be where a cache miss first shows up.
6. **Send before you need to.** For anything predictable — a reminder, a scheduled notice — the budget starts when you decide, not when the user waits.

## Designing the code screen for the slow case

```diagram:flow
# A code screen that survives a slow network
Show the wait | A visible timer beats a spinner. The user needs to know how long is normal.
Offer the alternative early | A "call me instead" or other-channel option at around ten seconds, not sixty. It arrives by a different path.
Never expire before arrival | A code valid for sixty seconds on a route that sometimes takes forty is a support ticket waiting to happen.
Allow one resend, then change route | A second attempt down the same slow path is not a different attempt.
Log the round trip | Per market, per hour. This is how you find the afternoon that is broken in one country.
> Every step here is interface work. None of it makes the network faster, and all of it makes the wait survivable.
```

## Retries that do not make it worse

Retry with backoff and a cap, and make retries safe for the recipient. The failure mode is not a slow message; it is four copies of the same code arriving at once, two already invalid.

A retry down the route that just failed is a second attempt at a failure: it adds load to a struggling path and delays the user further. Retry on a different route or channel, or tell the user instead — and stop after a small number of attempts. Systems without a ceiling produce the outage-day pattern where everyone is retrying and nothing gets through.

```diagram:checklist
# Retries that make it worse
[!] Four copies of the same code at once | Two already invalid — make retries safe for the recipient
[!] Retrying down the route that just failed | A second attempt at a failure: more load, more delay
[!] No ceiling | The outage-day pattern: everyone retrying, nothing getting through
```

## Live voice and video: milliseconds that change behaviour

For calls, the reference point is the ITU-T G.114 recommendation on one-way transmission delay: up to about 150 ms is acceptable for most conversations; between 150 and 400 ms is usable but noticeable; beyond 400 ms is not acceptable for normal conversation planning. In practice:

- **Distance matters.** Media relayed through a server on another continent can use most of that budget before any processing happens. Ask where media servers are, not only where the company is.
- **Jitter and packet loss feel like latency.** Buffers that smooth out jitter add delay; lost packets cause gaps. Good networks matter more than raw bandwidth.
- **Relays are common.** Even "peer-to-peer" WebRTC calls fall back to a relay (TURN) server when a direct path cannot be made, often on corporate or mobile networks.

```diagram:scale
# One-way delay on a call, per ITU-T G.114
Natural conversation | Not workable
Up to about 150 ms | 1 | Acceptable for most conversations
150 to 400 ms | 5 | Usable, but noticeable
Beyond 400 ms | 9 | Not acceptable for normal conversation planning
> Distance, jitter buffers and relays all spend from the same budget.
```

## A worked example

A fintech app saw complaints about login codes in one country only.

- **End-to-end measurement** showed a median of 4 seconds there but a 95th percentile of 38 seconds between 6pm and 10pm; other countries stayed under 10 seconds.
- **The cause** was a partner route with an aggregator hop that congested in the evening.
- **Changes:** a direct route for that country from a second provider; code validity raised from 60 to 180 seconds; a "send by voice call" option shown at 15 seconds; one resend allowed, on the other route.
- **Result:** the 95th percentile fell to 9 seconds, and failed logins in that country fell sharply. No line of the code-generation logic changed.

```diagram:stats
# Login codes in one country, evenings
38 s | 95th percentile, before | Between 6pm and 10pm; the median was 4 seconds
9 s | 95th percentile, after | A direct route, longer validity, a voice option at 15 seconds, one resend on the other route
> No line of the code-generation logic changed.
```

## What to ask a provider

- What are your median and 95th-percentile delivery times per country, measured to the delivery receipt — not to API acceptance?
- Which countries do you reach directly, and which through partners?
- What does a "delivered" receipt mean in each country, and how late can it arrive?
- For voice and video, where are your media and relay servers, and can I choose the region?

## Where to go next

Next in this track: [when video belongs in support](/en/learn/when-video-belongs-in-support). To put delivery-time commitments into an agreement, read [evaluating a CPaaS contract](/en/learn/evaluating-a-cpaas-contract); for how live media works underneath, see [WebRTC in plain terms](/en/learn/webrtc-in-plain-terms).

## Sources

[^1]: [ITU-T G.114: One-way transmission time](https://www.itu.int/rec/T-REC-G.114) — International Telecommunication Union
[^2]: [RFC 8656: Traversal Using Relays around NAT (TURN)](https://datatracker.ietf.org/doc/html/rfc8656) — IETF, 2020

---

Published by the company behind five products in this category. Those products appear in this site's directory alongside competitors under the same published criteria and are labelled as its own. Editorial content does not recommend them.