What 40 ms latency and 99.99% uptime actually mean for your users

Every API vendor prints a latency number and an uptime percentage on the pricing page. Both are easy to say and almost impossible to feel. 40 ms and 99.99% are not experiences, they're compressed statistics. So let's decompress them into the only units that matter to the person using your product: how many requests wait too long, and how many minutes a month your feature is simply gone. The numbers are more demanding than they look, and once you can read them properly you buy infrastructure differently.

The median is a comfort; the tail is the truth

An average latency of 40 ms tells you almost nothing, because an average is dominated by the boring middle and blind to the pain at the edges. A thousand fast calls and ten two-second calls still blend into a mean that looks perfectly healthy. What you actually want is the distribution, read as percentiles:

• p50 (median) — half of your calls are faster than this. It's the number vendors put on the homepage, because it's the flattering one.
• p95 / p99 — 1 in 20, and 1 in 100, calls are *slower* than this. The p99 is where the timeouts, retries and spinners actually live.
• p99.9 and `max` — the genuine worst case. max is usually the request that crossed your timeout and became an error, not a slow success.
• The gap is the story — a p50 of 40 ms with a p99 of 60 ms is predictable; a p50 of 40 ms with a p99 of 900 ms means someone is always waiting, you just can't see who from the average.

The tail matters more than intuition suggests, because pages rarely make a single call. Say one endpoint has a p99 of 400 ms — a 1% chance any given call lands in that slow tail. A page that makes n independent calls has a 1 - 0.99^n chance that *at least one* of them draws a tail request. That compounds fast:

• 1 call — 1 - 0.99^1 = 1% of loads hit the tail.
• 10 calls — 1 - 0.99^10 ≈ 9.6%. Roughly one in ten of your users meets the slow path on every load.
• 50 calls — 1 - 0.99^50 ≈ 39%. The p99 is now a near-coin-flip, not a rare event.
• ~69 calls — the tail crosses 50/50. Your “1-in-100” latency is now hitting half of your traffic.

This is tail amplification, and it's exactly why a fast p50 with a fat p99 is a trap. Cut the number of calls, cut the p99, or both — but never reason about a multi-call page from the median alone.

Four nines, counted in minutes

Uptime percentages have the same problem: they hide their meaning behind a decimal point. Convert them to downtime per month and the stakes get concrete immediately (a 30-day month is about 43,200 minutes):

• 99.9% — three nines — ≈ 43 minutes a month of downtime (about 8.8 hours a year). One bad deploy on a Friday and you've spent the budget.
• 99.99% — four nines — ≈ 4.3 minutes a month (about 52 minutes a year). A single short incident, caught and resolved before most people notice.
• 99.999% — five nines — ≈ 26 seconds a month (about 5 minutes a year). Effectively no human-perceptible downtime, and genuinely expensive to guarantee.

The jump from three to four nines is the difference between a bad afternoon and a coffee break — every month, forever. That's the tier worth paying for in a critical-path dependency. locabium runs a 99.99% uptime SLA with a public status page, so that 4.3-minute monthly budget is a number you can audit at https://api.locabium.com, not a slogan on a slide.

Latency compounds down a chain

A single 40 ms call is invisible. The damage happens when you chain calls, because in the naive version each one waits for the last. Picture a localize-on-checkout flow: look up the visitor's location from their IP, choose a currency from their country, then resolve their timezone for delivery estimates. Written the obvious way, those three 40 ms calls run in series and the page can't commit until all of them return — 120 ms of dead time, and you roll the p99 dice three times back to back.

// SERIAL — each call waits for the one before it, so the latencies stack.
const geo = await locabium.location({ ip })              // ~40 ms
const currency = await locabium.currency(geo.country)    // ~40 ms  (needs the country)
const tz = await locabium.timezone(geo.lat, geo.lon)     // ~40 ms  (needs the coords)
// wall-clock  ~120 ms  — and three separate chances to draw a slow tail

// PARALLEL — independent calls fire together off one key; you pay for the slowest, once.
const [email, phone, vat] = await Promise.all([
  locabium.validateEmail(form.email),
  locabium.validatePhone(form.phone),
  locabium.validateVat(form.vat),
])
// wall-clock  ~max(40, 40, 40)  ~45 ms

The rule is simple: if calls don't depend on each other's output, they must never wait for each other — Promise.all collapses three round trips into roughly one. When they genuinely do depend on each other, like currency needing the country from the location lookup, the answer isn't parallelism, it's consolidation: one enriched location response that returns country, currency and timezone together. Either way you go from three tail rolls to one, and from ~120 ms to ~40 ms. One API, one key, one round trip isn't a convenience — it's a latency budget.

Measure it at your edge, in percentiles

None of this is real until you measure it, and most teams measure it wrong. Two habits fix most of the blind spots:

• Percentiles, never averages — track p50, p95, p99 and p99.9 as separate series. A mean lets a wall of slow requests hide behind a healthy-looking number; a p99 refuses to.
• **Measure at *your* edge, not the vendor's** — a vendor's p99 is timed at their own door. Your user also pays for DNS, TLS, the public internet and your runtime on top. Instrument the call from where you actually make it, then compare — the delta is yours to own.
• **Synthetic *and* real-user monitoring** — scheduled synthetic probes from fixed locations give you a clean baseline that screams when a vendor regresses; RUM captures the messy truth across real devices, networks and geographies. Synthetic tells you *something changed*; RUM tells you *your users felt it*.
• Alert on the tail and the `max` — page on p99 and error rate, not on the average. The max is often a timeout wearing a latency costume: an error your latency graph politely hid.

What to demand from a data vendor

Once you can read the numbers, your vendor checklist changes. For anything on your critical path — geolocation, currency, validation — insist on all of these:

• Published percentiles, not an “average” — a serious vendor shows you p50/p95/p99. A single “average response time” on a marketing page is a number chosen to look good.
• An SLA with credits, not a promise — an uptime figure with no financial teeth is a wish. Credits make the vendor's on-call engineer feel your outage too.
• A public status page with history — live status plus an honest incident log. A vendor that hides outages is telling you how the next one will go.
• Regional PoPs / anycast — latency has a floor set by the speed of light. A single-region API adds 100–200 ms of round-trip for distant users no matter how fast the server is; points of presence near your traffic cap that floor.
• Client-side controls you own — sane timeouts and safe, idempotent retries, so one slow tail degrades gracefully instead of cascading into a full outage.

locabium is built to survive its own checklist: one API across eight endpoints — IP and GPS geolocation, timezone, currency, plus email, phone, VAT and IBAN validation — a sub-40 ms median, a 99.99% uptime SLA and a public status page you can read before you sign anything. The point isn't the marketing line — it's that every number here is one you can verify at your own edge.

Don't buy on the p50 and the headline uptime. Buy on the p99 and the downtime measured in minutes — those are the numbers your users actually live in.

— The locabium engineering team