English for Grafana Dashboard Reviews: Describing Metrics Clearly

When you share your screen and walk a colleague through a Grafana dashboard, the quality of your English directly shapes whether they understand the system’s health. Saying “the line goes up here” is far weaker than “p99 latency spiked at 14:00, then plateaued.” This guide gives you the precise vocabulary to describe metrics, trends, and dashboards in observability reviews.

The verbs of trends

Half of describing a dashboard is describing the shape of a line over time. English has rich vocabulary here — use it.

Going up:

• rise / increase — neutral, gradual. “Latency rose steadily through the morning.”
• climb — steady upward. “CPU climbed to 80%.”
• spike — sudden, sharp jump. “Error rate spiked at 14:00.”
• surge — a large, fast rise. “Traffic surged during the sale.”
• creep up — slow, almost unnoticed. “Memory has been creeping up all week.”

Going down:

• fall / drop / decrease — neutral. “Throughput dropped after the deploy.”
• plummet / crash — sudden, severe. “Availability plummeted to 60%.”
• taper off / decline — gradual fall. “Requests tapered off overnight.”

Staying level or steadying:

• plateau / level off / flatten out — stop changing. “Latency plateaued after we scaled up.”
• hold steady / remain flat — no change. “Error rate held steady at zero.”
• stabilise — settle after turbulence. “The metric stabilised once the cache warmed.”

Up and down:

• fluctuate — vary irregularly. “Memory fluctuates with garbage collection.”
• oscillate — swing regularly between values.
• be spiky / be noisy — full of short-lived jumps.

“p99 latency was flat until 13:50, then spiked to 2 seconds, plateaued for ten minutes, and tapered off once we shed load.”

Talking about magnitude and rate

Pair a trend verb with an adverb of degree or speed:

• sharply / steeply — fast and steep. “It rose sharply.”
• gradually / slowly / steadily — over time. “It declined gradually.”
• slightly / marginally — a little. “Throughput dipped slightly.”
• dramatically / significantly — a lot.

Quantify whenever you can:

• “Latency doubled, from 200ms to 400ms.”
• “Error rate jumped by an order of magnitude.”
• “Throughput is down 30% week over week.”
• “CPU hovers around 60%.”

Percentiles and statistics in plain English

Observability lives on percentiles. Say them naturally:

• p50 / median — “p fifty” or “the median”. “The median response is 50ms.”
• p95, p99 — “p ninety-five”, “p ninety-nine”. “p99 is our tail latency.”
• the tail — the slow extreme. “The tail is what hurts users.”
• percentile — “The 99th percentile crossed our SLO.”

Useful framings:

• “The median looks fine, but the tail is ugly.”
• “p50 and p99 have diverged — that points to a subset of slow requests.”
• “We’re breaching the SLO at p99 but not at p95.”

Describing the dashboard itself

• panel — a single chart. “The top-left panel shows request rate.”
• time range — the window shown. “Let me widen the time range to the last 24 hours.”
• the legend — the key explaining each line.
• to overlay — show two series on one chart. “I’ve overlaid deploys as annotations.”
• annotation — a marker on the timeline. “The red line marks the deploy.”
• threshold — a line marking a limit. “Anything above the red threshold is an alert.”
• to drill down / drill into — view more detail. “Let me drill into the per-pod breakdown.”
• to zoom in / zoom out — narrow or widen the view.

Navigation phrases for a live walkthrough:

• “Up top you can see … and below that ….”
• “If I hover over this point, you’ll see the exact value.”
• “Let me switch the time range to cover the incident window.”
• “This panel is broken down by region.”

The four golden signals — and how to say them

The standard observability signals each have natural phrasing:

• Latency — “how long requests take.” “Latency is climbing.”
• Traffic — “how much demand we’re getting.” “Traffic is flat.”
• Errors — “the rate of failed requests.” “Errors ticked up after the deploy.”
• Saturation — “how full the system is.” “We’re saturating the connection pool.”

Describing anomalies and correlations

When something looks off, say what’s unusual and what it correlates with:

• “There’s an anomaly here — a sharp spike that doesn’t match traffic.”
• “This correlates with the deploy at 14:00.”
• “The spike lines up with the cron job.”
• “Error rate and latency move together, which suggests a shared cause.”
• “This looks like a sawtooth pattern — probably memory filling up and getting reclaimed.”

Hedge when you’re inferring rather than stating fact:

• “It looks like the GC is the culprit.”
• “This could be retry amplification.”
• “My best guess is connection-pool exhaustion.”

Before and after

Before: “So yeah, here the line goes up a lot, then it’s kind of flat, and over here it’s bad.”

After: “p99 latency spiked to 2 seconds at 14:00 — that lines up with the deploy annotation — then plateaued for ten minutes before stabilising once we rolled back. The median barely moved, so it was a slow subset of requests, not everything.”

The second is the same length but tells a complete story.

Common mistakes

• “Go up / go down” for everything. Reach for spike, climb, plummet, taper — they carry precision.
• Reading numbers without interpretation. Don’t just say “it’s 2 seconds”; say whether that’s good, bad, or anomalous.
• Confusing average and percentile. “Average latency” hides the tail; say “median” or “p99” when that’s what you mean.
• No time anchors. Always tie a change to when it happened: “at 14:00”, “after the deploy”, “overnight”.

Key takeaways

• Use specific trend verbs: spike, climb, plummet, plateau, taper off, fluctuate.
• Quantify: doubled, up 30%, hovers around 60%.
• Say percentiles naturally and talk about the tail.
• Tie every change to a time anchor and look for correlations.
• Hedge inferences; state observations as fact.

Describe dashboards like this and your observability reviews will be sharper, faster, and far easier to follow.

Navigating Nuance: Common Pitfalls for Non-Native Speakers

Communicating effectively during a Grafana dashboard review, especially when your first language isn’t English, can feel daunting. It’s not just about stating what you see; it’s about conveying the implications of those data points with precision and confidence. Many non-native speakers find themselves hesitant to use strong verbs describing trends or struggling to articulate anomalies clearly. This hesitation often stems from a desire to avoid appearing overly assertive, which can be misinterpreted in a collaborative environment like code review. Let’s address some common areas where nuance is particularly important. One frequent issue is using vague language when describing changes. Instead of saying “the metric went up,” consider phrases that convey the extent and direction of the change. A simple “The metric increased by 15% during this period” is far more informative than a general statement. Similarly, when discussing percentiles, avoid simply stating “the 90th percentile is high.” Instead, try “The 90th percentile indicates that 90% of the values are below this level, suggesting potential bottlenecks or resource constraints.”

Another challenge often arises in describing anomalies – those unexpected spikes or dips. The phrase “something’s wrong” can be perceived as accusatory and unproductive. A more constructive approach is to frame the anomaly with cautious observation: “I’ve noticed a significant deviation from the baseline; let’s investigate the cause.” Or, if you have an initial hypothesis, “There appears to be a spike in traffic around 3 AM – perhaps related to scheduled maintenance?” Furthermore, when providing feedback on dashboard visualizations, avoid overly technical jargon unless absolutely necessary. Phrases like “the graph is misleading” can sound harsh. Instead, focus on the impact of the visualization: “This chart doesn’t clearly show the trend; perhaps a line graph would provide a more intuitive representation.” Remember, clarity and constructive criticism are key to productive collaboration.

Finally, consider the context of your communication – whether it’s a comment on a pull request, a Slack message discussing a dashboard, or a formal update. The level of formality should align with the situation. A quick Slack message might use more conversational language (“Hey team, I think we need to look closer at this spike”), while a PR description would require a more detailed and precise explanation. Always prioritize being understood over demonstrating perfect grammar – your goal is to facilitate understanding and drive positive change within the project. Focus on building trust through clear, actionable feedback.