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.

Understanding the Nuances for Non-Native Speakers

Communicating technical issues clearly is crucial, but describing latency – the delay between a request and its response – can be particularly challenging. Often, it’s not just about stating “it’s slow.” The key lies in precision and framing the problem effectively, especially when dealing with colleagues who might have different levels of English proficiency or technical background. For non-native speakers, mastering the specific vocabulary related to performance is paramount. It’s not enough to simply say “the system is lagging”; you need to articulate why it’s lagging, and quantify that delay where possible. This section will focus on equipping you with the language needed to navigate those conversations confidently, whether during a code review, an incident report, or a discussion about optimizing your application’s performance.

Think of latency as having multiple dimensions. You might experience high tail latency, referring to the long delays experienced by only a small percentage of requests – perhaps the 1% slowest. This is often far more critical than average latency because it directly impacts the user experience for those few individuals. Then there’s contention, where multiple processes are competing for the same resources, like database connections or network bandwidth, creating bottlenecks. Describing these concepts clearly requires careful phrasing. Instead of saying “the database is slow,” a more precise statement would be, “We’re observing elevated tail latency in our database queries, specifically p99 latency exceeding 500ms for requests originating from the mobile app.” This immediately provides context and suggests potential areas for investigation. Furthermore, identifying the root cause – whether it’s inefficient code, insufficient hardware resources, or network congestion – is essential for effective resolution.

Let’s consider a scenario: During a code review, you notice a slow API endpoint. You could simply say “This API is slow.” That doesn’t provide much actionable information. Instead, you might frame the issue as: “I’ve observed increased latency in this endpoint, specifically a p99 of 1.2 seconds. This appears to be due to excessive database locking during peak loads, potentially exacerbated by the recent scaling changes. I suggest we investigate query optimization and consider adding appropriate retry logic.” Notice how much more detailed and helpful that phrasing is – it directs attention to specific metrics (p99), potential causes (database locking, scaling changes), and proposed solutions (query optimization, retry logic).

Finally, remember that active listening plays a significant role. Don’t just throw technical jargon at someone; genuinely try to understand their perspective and adapt your communication style accordingly. Asking clarifying questions like “Could you elaborate on what you mean by ‘high latency’ in this context?” can be incredibly valuable.

# Example: Using `ping` to measure network latency

ping -c 5 google.com

This simple command, using the ping utility, demonstrates a basic way of measuring network latency – the time it takes for a packet to travel between your computer and Google’s servers. The output will show you the round-trip times (RTT) for each ping, which provides a direct measure of the delay. While ping is a quick diagnostic tool, remember that it only measures network latency; it doesn’t account for delays within the application itself.