Talaria

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

production

Throughput

184 / min

Error rate

1.8%

p95

420 ms

Apdex

0.94

7d · throughput / p95

Performance overview: throughput, error rate, p95, and Apdex over a selected window, with a toggleable series.

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 is

    Application 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 waterfall

    A 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 traces

    Alerts notice when RED crosses a line you set. AI reads the traces and issues you already have. Neither is an autonomous SRE.

Turn tracing on

Opt into enableTracing on an official SDK, then inspect transactions next to the issues they belong to.