Latency
Measured PayPal sandbox latency and the targets it does not meet.
Measured on the real PayPal sandbox on 5 Nov 2026 (workflow measure-sandbox, 10 sequential cycles, 0 failures, so n=10 per call).
| Call | p50 (ms) | p95 (ms) | max (ms) |
|---|---|---|---|
| order | 650.88 | 758.5 | 758.5 |
| authorize | 1299.04 | 2268.65 | 2268.65 |
| capture | 1871.69 | 2280.66 | 2280.66 |
| void | 939.76 | 1235.96 | 1235.96 |
Targets
| Target | Value | Status |
|---|---|---|
| hammer to CAPTURED, p95 | 2.5 s | Missed. End to end, n=20 with 6 holds: p95 3010.04 ms. The capture call alone has p95 2280.66 ms (n=10, 5 Nov), which leaves little room for the truth check and journal writes. |
| hammer to SETTLED, 6 holds, p95 | 6 s | Met. End to end, n=20 with 6 holds: p95 5591.30 ms. |
| webhook handler 200, without the verify call | 300 ms | Not measured by this script. |
A settlement of six holds is one truth check, one capture and five voids. With three voids at a time that is two void waves. Using sandbox p95 for the capture and void calls alone gives 2 x 1235.96 + 2280.66 = 4752.58 ms before the truth check. The end-to-end run includes the truth check and came in at 5591.30 ms p95, inside the 6 s target with about 0.4 s of margin on this sample of 20.
The end-to-end settlement measurement (npm run measure:settlement -w @gavel/e2e) runs only through the measure-sandbox workflow from main, in mode settlement. Run 42346811713 (20 settlements of 6 holds, 0 failed) has a redacted copy under docs/evidence/measure/. Its status in docs/GATES.md is PARTIAL: one target met, one missed.
- docs/GATES.mdsection "Latency targets and measured numbers"
- packages/e2e/src/sandbox/measure-settlement-cli.tsend to end settlement measurement
Last updated on