How to Explain Latency Issues in English: Describing Performance Problems

Performance problems are hard enough to debug. Explaining them out loud — to a teammate, a manager, or a customer — adds a second challenge. You need words for how slow, where the slowness is, and what’s causing it. This guide gives you the spoken English to describe latency issues clearly and credibly.

The vocabulary of “slow”

“It’s slow” is the weakest thing you can say. Reach for precise terms:

• latency — the time a single request takes. “Latency is up across the board.”
• throughput — how many requests you handle per second. “Throughput dropped to half.”
• response time — how long the user waits. “Response times doubled.”
• bottleneck — the slowest part that limits everything. “The database is the bottleneck.”
• tail latency — the slow extreme (p99, p999). “The median’s fine; it’s the tail that hurts.”
• jitter — variation in latency. “There’s a lot of jitter on this path.”
• cold start — slow first request after idle. “Cold starts add 800ms.”
• warm-up — the period before caches fill and things speed up.

“The median’s healthy at 40ms, but p99 is at 2 seconds — the tail is killing us.”

Describing how slow, precisely

Don’t say “very slow.” Quantify and compare.

• “Latency doubled, from 200 to 400 milliseconds.”
• “We’re seeing 2-second response times at p99.”
• “It’s up 40% since the deploy.”
• “Requests are timing out after 30 seconds.”
• “It’s an order of magnitude slower than yesterday.”

Always attach a percentile or a baseline. “Slow compared to what?” is the first question you’ll get.

Saying where the slowness is

A clear explanation localises the problem. Use spatial and structural language:

• “The slowness is on the read path, not the write path.”
• “It’s upstream of the cache — the cache itself is fine.”
• “The time is being spent in the database, specifically a single query.”
• “It’s at the network layer — the app code is fast.”
• “The bottleneck is downstream, in the payments service.”

Upstream = earlier in the flow, towards the source. Downstream = later, towards the consumer. Getting these right makes you sound precise.

Naming the cause

Common latency causes each have natural phrasing:

• contention — components fighting for a shared resource. “There’s lock contention on the orders table.”
• resource exhaustion — running out of something. “We exhausted the connection pool.”
• N+1 queries — one query per row instead of one batched query. “It’s an N+1 — we hit the DB once per item.”
• head-of-line blocking — one slow request holding up the rest.
• retry storm / retry amplification — retries multiplying load. “Retries are amplifying the problem.”
• GC pause — garbage collection freezing the app. “A long GC pause stalled the service.”
• thundering herd — many clients hitting at once after a cache expiry.
• chatty calls — too many small network round-trips. “The service is too chatty.”

“It’s a classic N+1 — the page loads fine with ten items but falls over with a thousand because we query the DB per row.”

Cause-and-effect language

Linking cause to effect clearly is what makes an explanation land:

• “The spike in latency is caused by the connection pool filling up.”
• “When the cache expires, traffic floods the database, which drives latency up.”
• “The slow query blocks the connection, so other requests queue behind it.”
• “As load increases, contention rises, which in turn increases latency.”

Useful connectors: because, so, which means, which in turn, as a result, leads to, drives up.

Phrases for the incident channel

• “p99 latency spiked at 14:00, lining up with the deploy.”
• “We’re seeing tail latency without a rise in traffic — that’s the weird part.”
• “The bottleneck is a single slow query; I’ve got the EXPLAIN plan.”
• “It’s contention, not capacity — adding replicas won’t help.”
• “Latency recovered once we shed load.”
• “This smells like a retry storm.”

The verb to shed load (drop some requests deliberately to recover) and the phrase “this smells like” (an informal hunch) are both very natural.

Explaining to a non-technical audience

When you talk to a manager or customer, drop the jargon and use analogies:

• “Think of it like a checkout line — one slow cashier backs up everyone behind them.”
• “Most requests are fast, but the slowest 1% are very slow, and those are the ones users complain about.”
• “We were running out of ‘lanes’ to handle requests, so they queued up.”

Lead with impact, not mechanism:

• “Users on the checkout page are waiting up to 5 seconds. We’ve found the cause and we’re deploying a fix now.”

Before and after

Before: “The site is slow. Something’s wrong with the server I think. It’s been bad for a while.”

After: “p99 latency on checkout jumped from 300ms to 2 seconds around 14:00, right after the deploy. The cause is an N+1 query that only shows up with large carts. The median is fine, so most users aren’t affected — it’s the heavy carts hitting the tail. We’re batching the query and deploying in 20 minutes.”

Same situation, but now everyone knows how slow, for whom, why, and when it’s fixed.

Common mistakes

• “It’s slow” with no number. Always give a value and a baseline.
• Confusing latency and throughput. Latency is per-request; throughput is per-second.
• Reporting the average. The average hides the tail. Use median and p99.
• Mixing up upstream and downstream. Know which direction you mean.
• Leading with mechanism for a non-technical audience. Lead with impact, then explain.

Key takeaways

• Quantify slowness with a percentile and a baseline.
• Localise it: read vs write path, upstream vs downstream, which layer.
• Name the cause: contention, N+1, retry storm, GC pause, exhaustion.
• Use cause-and-effect connectors: which means, drives up, as a result.
• For non-technical listeners, lead with impact and use an analogy.

Explain latency like this and people will trust both your diagnosis and your fix.