```meta
title: Request latency across the fleet
subtitle: Where the 250 ms alert threshold sits on the latency curve.
tag: DRAFT
```

The alert fires when a host's p95 request latency stays above 250 ms for five minutes. The question is where 250 ms sits on the curve. In the tail, only degraded hosts cross it. Inside the bulk, healthy hosts page us. The data below is a seven-day sample from the `api-edge` fleet: 48 hosts in three pools, one sample per host per minute.

```callout
tone: note
title: Assumptions
body: "The fleet is the `api-edge` service, 48 hosts across the pools `us-east`, `us-west`, and `eu-central`. Latency is server-side time from first byte received to last byte sent, in milliseconds. The threshold applies to per-host p95 over a five-minute window. All figures are invented to be realistic; replace them with the real export before this leaves DRAFT."
```

## Fleet-wide latency distribution

Most requests finish between 60 ms and 180 ms. The curve is right-skewed: a long tail past 250 ms comes from cold caches after a deploy and from `eu-central` cross-region reads. The threshold sits past the bulk, so a healthy host crosses it only when its tail grows.

```chart
kind: histogram
title: Request latency, all pools, 7 days
xLabel: Latency
yLabel: Requests
unit: ms
bins: 16
values: [42, 48, 55, 58, 61, 63, 66, 68, 70, 71, 73, 74, 76, 77, 79, 80, 82, 83, 84, 85, 86, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 142, 144, 146, 148, 150, 152, 154, 156, 158, 160, 163, 166, 169, 172, 175, 178, 182, 186, 190, 195, 200, 206, 212, 219, 227, 236, 246, 258, 271, 285, 300, 318, 340, 366, 398, 440, 495, 570, 680, 840, 1100]
markers:
  - { at: 250, label: Alert threshold, accent: red }
```

## Percentiles per pool

The threshold is a p95 rule, so the pool view shows which pools live near it. `us-east` and `us-west` keep p95 under 200 ms and cross 250 ms only at p99. `eu-central` runs its p95 at 240 ms, 10 ms under the line, so any deploy or cache flush there pages on-call.

```percentiles
title: Latency percentiles by pool, 7 days
unit: ms
slo: 250
rows:
  - { label: us-east (20 hosts), p50: 88, p90: 150, p95: 182, p99: 290, max: 1100 }
  - { label: us-west (16 hosts), p50: 94, p90: 158, p95: 194, p99: 310, max: 980 }
  - { label: eu-central (12 hosts), p50: 121, p90: 205, p95: 240, p99: 410, max: 1400, accent: amber }
```

## The threshold against the fleet numbers

Fleet-wide p95 is 205 ms, 45 ms under the budget. Fleet-wide p99 is 335 ms, over the budget, which is expected: the alert is a p95 rule and p99 is not gated. The near miss is `eu-central` p95, and the fix is a regional read replica, not a higher threshold.

```perfbudget
title: 250 ms budget vs measured
context: per-host p95 unless stated, 7-day window
metrics:
  - { metric: Fleet p50, budget: 250, measured: 98, unit: ms }
  - { metric: Fleet p95, budget: 250, measured: 205, unit: ms }
  - { metric: eu-central p95, budget: 250, measured: 240, unit: ms, note: "10 ms of headroom; pages on any cache flush" }
  - { metric: Fleet p99 (not gated), budget: 250, measured: 335, unit: ms, note: "Over budget by design; the alert is a p95 rule" }
```

Keep the threshold at 250 ms. Move the alert window from five minutes to ten for `eu-central` until the read replica ships. Revisit the threshold when the fleet p95 drops under 150 ms.