Vocabulary for Talking About Observability and Monitoring
Essential English vocabulary for observability and monitoring: metrics, logs, traces, SLOs, alerting, and the phrases engineers use to discuss system health.
Observability is how teams understand what their systems are actually doing in production. The field has a dense vocabulary — metrics, traces, SLOs, percentiles — and using it precisely marks you out as someone who knows operations. This guide covers the essential terms, common phrases, and example sentences for discussing system health in English.
The Three Pillars
| Term | Meaning |
|---|---|
| Metrics | Numerical measurements over time (e.g. requests per second). |
| Logs | Timestamped records of events. |
| Traces | The path of a single request through your services. |
“The metrics show a latency spike, but I need to look at the traces to see which service is slow.”
These three are often called “the three pillars of observability” — a phrase worth knowing.
Metrics Vocabulary
- Latency — how long a request takes.
- Throughput — how many requests per second.
- Error rate — the percentage of failing requests.
- Saturation — how full a resource is (CPU, memory, disk).
- Percentile (p50, p95, p99) — the value below which X% of requests fall.
“Our p99 latency is 800ms, which means 1% of users are waiting nearly a second.”
Percentiles matter because averages hide the worst experiences. Saying “p95” shows you understand that.
SLOs, SLAs and SLIs
These three are easy to confuse, so be precise:
| Term | Meaning |
|---|---|
| SLI | Service Level Indicator — what you measure (e.g. uptime). |
| SLO | Service Level Objective — your internal target (e.g. 99.9%). |
| SLA | Service Level Agreement — a contractual promise to customers. |
| Error budget | How much unreliability you can “spend” before breaching the SLO. |
“We’ve burned through most of our error budget this month, so we should pause risky deploys.”
Alerting Vocabulary
- to fire an alert — when an alert triggers.
- to page someone — to wake the on-call engineer.
- alert fatigue — being overwhelmed by too many alerts.
- a flapping alert — one that triggers and clears repeatedly.
- a noisy alert — one that fires too often to be useful.
“This alert is too noisy — it’s paging us at 3am for a non-issue. Let’s tune the threshold.”
Describing System Behaviour
| Phrase | Meaning |
|---|---|
| ”It’s degraded.” | Working but slow or partial. |
| ”It’s flapping.” | Switching between healthy and unhealthy. |
| ”We’re seeing elevated error rates.” | More errors than normal. |
| ”It’s saturated.” | A resource is at capacity. |
| ”There’s a memory leak.” | Memory use grows over time. |
“The service is degraded — it’s up, but response times are double the baseline.”
The word “baseline” (normal level) is essential for comparing current behaviour to usual.
Verbs You’ll Use Constantly
- to instrument code (add observability to it)
- to scrape metrics (collect them)
- to correlate logs and traces
- to drill down into a metric
- to dashboard something (informal: put it on a dashboard)
- to alert on a condition
“We need to instrument the checkout flow so we can trace where the latency is coming from.”
Useful Phrases in an Investigation
“Let me drill down into the p99 by endpoint.” “The error rate started climbing right after the 14:00 deploy.” “I can’t correlate these logs without a trace ID — let’s add one.” “The dashboard’s showing a clear spike, but the cause isn’t obvious yet.”
Words People Confuse
| Confused | Clarification |
|---|---|
| Monitoring vs observability | Monitoring watches known problems; observability helps explore unknown ones. |
| Logs vs traces | Logs are events; traces follow one request across services. |
| Latency vs throughput | Latency is speed per request; throughput is volume. |
| SLO vs SLA | SLO is your internal goal; SLA is the customer contract. |
A Sentence to Practise
“Our SLI is request latency, our SLO is p95 under 300ms, and we’ve nearly exhausted this quarter’s error budget — so I’d recommend freezing risky changes and focusing on reliability until it recovers.”
Delivering that fluently signals real operational maturity.
Hedging and Uncertainty
In an incident you’re often unsure. English has precise hedges:
- “The metrics suggest a database bottleneck.”
- “It looks like a memory leak, but I haven’t confirmed it.”
- “We’re fairly confident the deploy caused this.”
With this vocabulary you can move fluently through any observability discussion — from describing a degraded service, to drilling into a p99 spike, to debating whether you’ve blown your error budget. Use the example sentences as templates, keep your SLIs, SLOs and SLAs straight, and hedge honestly when you’re still investigating.
Navigating Nuances: Common Phrases & Their Implications
Let’s be honest – the terminology around observability can feel dense, especially when you’re trying to communicate effectively with a team that might have different backgrounds or levels of technical expertise. Beyond just knowing what something is (a metric, a trace, etc.), it’s crucial to understand how those terms are used in practice and the subtle implications they carry. Often, misunderstandings arise not from a lack of knowledge about the underlying concepts, but from differing interpretations of how these terms are applied or prioritized. For example, a junior engineer might focus solely on increasing the number of metrics collected, without considering the cost – in terms of infrastructure and team time – associated with that data. Similarly, someone unfamiliar with tracing might suggest adding trace instrumentation everywhere, completely disregarding potential performance impacts.
A key area to watch out for is framing discussions around impact. When describing a problem or proposing a solution, engineers frequently use phrases that subtly shift the focus. Saying “the system is experiencing high latency” immediately suggests an urgent issue requiring immediate attention, whereas saying “we’re seeing elevated latency in several regions” sounds more measured and invites discussion about root causes rather than jumping to conclusions. Similarly, describing a metric as “critical” carries significantly more weight than simply stating it’s “high.” Using precise language – like “the 95th percentile of request duration is exceeding the SLO threshold” – forces a more data-driven conversation and avoids emotive language that can lead to misinterpretation.
Another common pitfall is failing to clearly articulate why something matters. Simply reporting that “logs are high” doesn’t provide context or urgency. Instead, describing a specific pattern in the logs—e.g., “We’re observing an increase in 404 Not Found errors originating from user requests to the /api/v1/users endpoint”—immediately highlights a potential problem and directs attention to a specific area of the system. This level of detail is vital for effective collaboration.
Finally, remember that clear communication extends beyond written documentation or Slack messages. Verbal discussions often benefit from structured approaches, like using pre-defined categories when describing issues during standups—a ‘severity’ rating alongside the technical details allows for efficient prioritization.
# Example: Using Prometheus to query latency metrics
promql "rate(http_request_duration_seconds_sum{job='my-app'}[5m])"This query demonstrates how a specific metric (HTTP request duration) is being monitored using PromQL, showcasing the practical application of observability principles. The rate() function calculates the per-second increase in the sum of durations over a 5-minute window, providing a dynamic view of system performance. This kind of concrete example helps solidify understanding of how metrics are collected and interpreted within an observability context.