Signals · 3 min read · Updated 2026-08-14
RED metrics: rate, errors, duration
Three numbers that describe a service from the outside: how often it is called, how often it fails, and how long it takes.
If you can only keep three application metrics, keep these. Tom Wilkie’s RED method — rate, errors, duration — is the application-facing half of SRE’s golden signals. Saturation stays on the host. RED stays on the request.
The problem
Teams drown in custom dashboards because every layer emits something. CPU, GC, queue depth, cache hit ratio — all useful in context, none of them the first answer to “is checkout OK?” The first answer is: are people hitting it, are they failing, and how long are they waiting?
What it is
- Rate (throughput) — sampled transactions per minute or second for a route or service.
- Errors — the fraction of those transactions with span status
error. - Duration — a latency distribution. Averages lie; p95 and p99 show the tail users actually feel.
Apdex is a companion score, not a fourth golden signal. It classifies requests as satisfied, tolerating, or frustrated against a threshold, then folds that into 0–1. It is a conversation tool (“we dropped below 0.9 after the deploy”), not a substitute for looking at p95.
Performance
storefront
Throughput
184 / min
Error rate
1.8%
p95
420 ms
Apdex
0.94
7d · throughput / p95
What it gives a team
- A one-screen health check for the app, not the cluster.
- A way to see whether a deploy changed traffic shape, failure rate, or latency — three different incidents.
- A threshold language for performance alerts: error rate, p95, or throughput crossing a line you chose.
How Talaria does it
ClickHouse materialized views aggregate root spans into span_red_1m (count, errors, p50/p95/p99 by project, service, route, environment, minute). The dashboard calls SpansEndpoint.redSeries and renders stat tiles plus an area chart you can toggle across throughput, p95, and errors. Time range controls cover 7 / 14 / 30 days.
This is a prebuilt Performance overview, not a custom dashboard builder. That is intentional: the job is to read the three signals, then open a waterfall.
How to read it
- Throughput down + errors up — dependency or deploy failure. Open error traces.
- Throughput flat + p95 up — something on the critical path got slower. Open a slow transaction.
- Errors up + p95 flat — failures that return quickly (4xx/5xx without waiting). Check issue grouping and the failing peer on Dependencies.
- Apdex down with a quiet p95 — a larger share of requests crossed the “tolerating” line even if the extreme tail did not move much.
Turn it on
RED series fill after sampled transactions arrive. Enable tracing on an official SDK. Without ClickHouse, the overview is empty — span storage is not optional for this view.
What this is not
Talaria does not ingest custom counters, gauges, or histograms as a metrics product. There is no PromQL, no user-defined dashboard, and no host saturation series. Environment, release, and route exist on the query object; the overview UI currently exposes the time range.
Related guides
Signals · 3 min
What SDK-native APM actually isApplication performance from inside your process — transactions, RED, and release health — without a host agent or an observability maze.
Signals · 3 min
How to read a request waterfallA waterfall is the trace drawn as time. The critical path is the longest chain of parent-to-child work — that is usually the fix.
Triage loop · 3 min
Performance alerts and AI on tracesAlerts notice when RED crosses a line you set. AI reads the traces and issues you already have. Neither is an autonomous SRE.