How to Explain Prometheus Metrics to Non-SRE Teams (Without Losing the Room)

How to explain Prometheus metrics to non-SRE teams (and why it’s hard)

Picture the post-incident review. You share a Grafana board with 24 panels, three of them titled rate(...). The VP of Product squints and asks the only question that matters: “So… were customers affected?” And you realize the dashboard can’t answer that without you narrating it.

That’s not a people problem. It’s a translation problem. Prometheus dashboards are built by engineers, for engineers, mid-incident. Product, support, finance and leadership show up with different questions, and a wall of time series isn’t an answer to any of them.

The fix isn’t a PromQL workshop for the whole company. It’s learning to explain Prometheus metrics in three moves: name what kind of number it is, connect it to a question someone actually has, and express it in units humans already use (people, orders, seconds, dollars).

Hot take: if a metric needs you in the room to be understood, it isn’t observability yet. It’s a private diary.

Prometheus metric types explained in plain English

Every Prometheus metric is one of four types, and each type answers a different kind of question. Per the official Prometheus metric types docs, a counter is a cumulative value that can only increase or be reset to zero on restart, while a gauge is a single numerical value that can arbitrarily go up and down. Here’s the cheat sheet to keep handy:

Counter vs gauge: the odometer and the fuel gauge

The single most common mistake when presenting Prometheus metrics is showing a raw counter. “Total requests: 8,412,330” tells nobody anything; it just keeps climbing. What people want is speed, not distance travelled, so you wrap counters in rate():

# Counter → "requests per second" (averaged over the last 5 minutes)
sum(rate(http_requests_total{job="checkout"}[5m]))

# Gauge → "what share of memory is free right now" (node_exporter)
node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes

Say it out loud: “Checkout is handling about 140 requests a second, and this node has 22% of its memory free.” That sentence lands in any meeting. The query behind it stays your business.

Lead with the four golden signals, not metric names

Your Prometheus instance probably exposes thousands of series. Non-SRE teams need about four ideas. Google’s SRE book chapter on monitoring distributed systems names them the four golden signals, and they map almost perfectly onto questions the business already asks:

• Latency, the time it takes to service a request. Business version: “How long are people waiting?”
• Traffic, how much demand is placed on the system. Business version: “How busy are we?”
• Errors, the rate of requests that fail. Business version: “How many people hit a wall?”
• Saturation, how “full” the service is. Business version: “How close are we to running out of room?”

The error signal is the easiest win. Present it as a ratio, then convert it to people:

# Share of checkout requests failing with 5xx in the last 5 minutes
# (label names like "status" vary with your instrumentation)
sum(rate(http_requests_total{job="checkout", status=~"5.."}[5m]))
  /
sum(rate(http_requests_total{job="checkout"}[5m]))

A result of 0.002 is meaningless to most people. “2 out of every 1,000 checkout attempts are failing” is a sentence a support lead can act on. Build a dashboard per service with just these four signals and watch the follow-up questions drop.

What is p99 latency? Explaining percentiles without a stats lecture

Averages are comfortable and mostly lie. The SRE book gives the classic example: a web service with an average latency of 100 ms at 1,000 requests per second, where 1% of requests might easily take 5 seconds. The average looks great while ten real users every second are staring at a spinner.

So skip “p99” as a term and say what it means: “99 out of 100 requests finished in under X seconds. The unlucky 1 in 100 waited longer.” Everybody understands “the unlucky one in a hundred.” Here’s how to get the number from a classic histogram, using the pattern from the Prometheus histograms and summaries guide:

# "How slow is it for the unlucky 1 in 100?" (p99, last 5 minutes)
histogram_quantile(
  0.99,
  sum by (le) (rate(http_request_duration_seconds_bucket{job="checkout"}[5m]))
)

# Even friendlier: "what share of requests finished within 300 ms?"
# (needs a bucket boundary at exactly le="0.3")
  sum(rate(http_request_duration_seconds_bucket{job="checkout", le="0.3"}[5m]))
/
  sum(rate(http_request_duration_seconds_count{job="checkout"}[5m]))

That second query is lowkey the best metric you can show a non-technical audience. “96% of checkouts finished in under 300 ms” needs zero explanation, and it maps cleanly onto a target the business can agree on.

One caution for the SREs in the room: if a service exposes a summary instead of a histogram, its percentiles are computed per instance by the app, and the Prometheus guide warns that averaging those quantiles across instances yields statistically nonsensical values. Prefer histograms for anything you aggregate.

Make metric names readable with Prometheus recording rules

Even with perfect explanations, a 90-character PromQL expression on a panel scares people off. Recording rules fix that: Prometheus evaluates the query on a schedule and stores the result under a new name, so dashboards (and humans) refer to the short name instead.

The Prometheus recording rules best practices recommend names of the general form level:metric:operations, which reads almost like a sentence: aggregation level, what was measured, and what was done to it.

groups:
  - name: checkout-golden-signals
    rules:
      # Traffic: requests per second, per job
      - record: job:http_requests:rate5m
        expr: sum by (job) (rate(http_requests_total[5m]))

      # Errors: share of requests failing with 5xx
      - record: job:http_requests_errors:ratio_rate5m
        expr: |
          sum by (job) (rate(http_requests_total{status=~"5.."}[5m]))
            /
          sum by (job) (rate(http_requests_total[5m]))

      # Latency: p99 request duration in seconds
      - record: job:http_request_duration_seconds:p99_rate5m
        expr: |
          histogram_quantile(0.99,
            sum by (job, le) (rate(http_request_duration_seconds_bucket[5m])))

Validate the file with promtool check rules checkout-rules.yml before you ship it. Then title each Grafana panel as the question (“What share of checkouts are failing?”) and put the recording rule underneath. Engineers get the precise definition; everyone else gets the question.

The vibe check: could someone in support read the panel title and the description and know whether to escalate? If yes, ship it.

Translate metrics into business impact for each audience

Same data, different question. The trick to explaining Prometheus metrics to non-SRE teams is matching the signal to what each group is actually worried about. Example phrasings:

Notice the pattern: every “say it like this” uses people, orders, seconds or money, never a metric name. When finance asks about cost, saturation next to traffic tells the story better than any bill breakdown. When leadership asks about an outage, error ratio multiplied by traffic gives you “roughly how many requests failed,” which converts directly into revenue at risk.

Want to go one level deeper on the incident side? Our guide on how to reduce MTTR with AI shows how to break an outage into phases that are just as easy to explain to leadership.

Checklist: make Prometheus metrics self-serve for non-SRE teams

Explaining metrics once is a meeting. Making them self-explanatory is a system. Run this in order:

1. 1Pick 3–5 customer-facing services. Don’t start with the whole cluster.
2. 2For each one, write a plain-English question per golden signal: “How many requests?”, “How many failed?”, “How slow were the slowest?”, “How full are we?”
3. 3Answer each question with a recording rule that has a readable name.
4. 4Build one service-health dashboard per service. Title every panel as the question it answers, in human units: requests per second, % failed, seconds.
5. 5Add a one-line description to every panel: what it means, what “good” looks like, and who to ping when it isn’t.
6. 6Publish a short glossary (counter, gauge, p99, error ratio, saturation) and link it from the dashboard.
7. 7Give people a way to ask follow-up questions in plain English instead of opening a ticket for the SRE team.
8. 8Once a month, delete panels nobody opened.

Step 7 is where most teams stall, because every follow-up still lands on an SRE’s desk. That’s the gap HealR’s Agent Chat for metrics is built for: people ask questions about metrics in plain English, no PromQL needed, and can upload a dashboard to get it analyzed. It works with the tools you already run, including Prometheus and Grafana.

And when someone needs a whole view rather than one answer, DashboardGPT builds dashboards from natural language, picks suitable chart types automatically, and lets you edit the result or export it to Grafana. For a tour of the conversational side, see Agent Chat for Metrics: conversational observability.

FAQ: explaining Prometheus metrics