Skip to main content
Metrics type: Key MetricsCategory: Performance

At a glance

The 95th-percentile service latency for SQL statements across the cluster, in milliseconds. Ninety-five out of every hundred statements completed faster than this number; the slowest five percent took longer. p95 is the tail-sensitive read of cluster health: it moves before the median does when contention, range splits, or an overloaded node start to bite. For an SRE this is the “is the database starting to hurt?” gauge, and it is the first number to check when an application team reports intermittent slowness that the p50 cannot explain.

Calculation

CockroachDB maintains an HDR histogram of statement service latency on every node, exported as the sql.service.latency metric family. The p95 quantile is the value below which 95 percent of recorded statements fall within the window. Vortex IQ derives the displayed number as follows:
  1. Poll sql.service.latency-p95 from each live node’s _status/vars endpoint over the rolling 5-minute window described by RT/5m.
  2. Take the cluster-wide quantile, not a naive average of per-node p95 values. Averaging percentiles understates the tail; Vortex IQ requests the merged-histogram quantile from the cluster status layer so the figure matches what the DB Console reports.
  3. Convert nanoseconds to milliseconds and round to one decimal place.
  4. Compare against the > 200ms alert threshold; if the rolling value stays above it for the configured dwell, the card flips to an alert state and feeds the alert-rules layer.
Because p95 is a percentile and not a mean, it is not additive: you cannot sum or average two windows’ p95 figures to get a combined p95. To reason across a longer period, read the histogram, which Vortex IQ retains, rather than arithmetic on the headline.

Worked example

A platform team runs a 6-node CockroachDB cluster (v23.2) backing an order-management service. Baseline p95 sits around 38ms during business hours. Snapshot taken on 14 Apr 26 at 09:42 BST during a morning traffic ramp. The cluster-wide p95 headline reads 214ms, above the 200ms threshold, so the card is in an alert state. The p50 sibling barely moved (it reads 11ms cluster-wide), which is the tell: this is a tail problem, not a broad slowdown. Everything looks fine “on average”. Reading across the nodes, n3 is the outlier: its p50 and p95 are both roughly 6x the rest. That points to a hot node, a single node carrying a disproportionate share of leaseholders for a contended range. The team confirms by opening Range Lease Balance Skew % (reads 31%, above its own 25% threshold) and Replicas per Node, which shows n3 holding more leaseholders than its peers.
Three takeaways:
  1. p95 moving while p50 holds is a tail signature, not a capacity signature. If both rose together you would suspect overall load or undersized nodes. p95-only points at a subset of statements (a contended range, a missing index on one query, a single hot node).
  2. Find the node, then find the range. The per-node view localised it to n3; the next step is SHOW RANGES plus the contention siblings to find which range’s leaseholder is the bottleneck. A manual lease transfer or a range split often clears it in minutes.
  3. 200ms is a default, not a law. A reporting cluster running heavy analytical statements may legitimately sit at p95 of 800ms and be perfectly healthy. Tune the alert threshold in the Alert Rules tab to your workload’s real baseline so the card alerts on regressions, not on normality.

Sibling cards

Reconciling against the source

Where to look in CockroachDB’s own tooling:
DB Console → Metrics → SQL dashboard → “Service Latency: SQL, 95th percentile” is the canonical chart. Confirm the time range matches the Vortex IQ window. DB Console → SQL Activity → Statements sorts by statement-level latency so you can find the contributing statements. SELECT * FROM crdb_internal.node_statement_statistics gives the raw per-statement latency stats from SQL. curl http://<node>:8080/_status/vars | grep sql_service_latency exposes the raw Prometheus histogram buckets if you want to compute the quantile yourself. For CockroachDB Cloud (Serverless or Dedicated), the same chart lives in the Cloud Console under Monitoring → SQL, and the Metrics export endpoint feeds Prometheus/Datadog with the identical metric name.
Why our number may legitimately differ from the DB Console: Cross-connector reconciliation:

Known limitations / FAQs

Why does p95 spike while my average latency looks fine? Because the average is dominated by the fast majority. p95 is a percentile: it deliberately reports the slow tail. A handful of contended or badly-planned statements can push p95 to 200ms while the mean stays in single digits. That is exactly why the tail percentiles, not the average, are the early-warning gauges. Read p95 alongside Statement Latency p50 (ms): a wide p50-to-p95 gap is the diagnostic signal. Can I add per-node or per-statement p95 figures together to get a cluster figure? No. Percentiles are not additive. You cannot sum or average per-node p95 values to get a cluster p95, nor average two time windows. Vortex IQ computes the cluster figure from the merged histogram for this reason. If you need a combined period, read the underlying histogram rather than doing arithmetic on headlines. My cluster runs heavy analytical statements and p95 is always above 200ms. Is it broken? Probably not. The 200ms default suits OLTP workloads. Analytical and reporting workloads legitimately run long statements and will sit higher. Retune the threshold in the Alert Rules tab to your real baseline so the card alerts on regressions from your normal, not against a generic default. The DB Console shows a lower p95 than Vortex IQ. Which is right? Both, usually. The most common causes are (1) you are looking at one node’s chart rather than the cluster merge, (2) you are looking at “SQL exec latency” rather than “Service latency”, which excludes planning, or (3) the chart window is longer than the rolling 5-minute window and has smoothed the tail. Align all three and the numbers converge. Does this include the client-to-cluster network time? No. sql.service.latency is measured inside the gateway node, from request receipt to result ready. Client network round-trip is not included. If application-side p95 is much higher than this card, the extra time is in the network or the application driver, not in CockroachDB. Compare against your APM’s database-span timing. A single node shows a much higher p95 than the others. What does that mean? Almost always a hot node holding skewed leaseholders for a contended range, or a node with a disk or CPU problem. Check Range Lease Balance Skew % and Replicas per Node first. A manual lease transfer or a range split usually rebalances the load and clears the tail within minutes. Does Vortex IQ count internal/background statements? The headline targets application-facing statements where the metric labelling allows the split. CockroachDB runs internal statements (jobs, schema changes, stats collection) that can be noisy; the DB Console may include them. If your figures diverge during a schema change or a large job, that is the likely reason.

Tracked live in Vortex IQ Nerve Centre

Statement Latency p95 (ms) is one of hundreds of KPI pulses Vortex IQ tracks across CockroachDB and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. Start for free or book a demo to see this metric running on your own data.