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.