Latency
Measured PayPal sandbox latency and the targets it does not meet.
Measured on the real PayPal 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 |
|---|---|---|
| to CAPTURED, p95 | 2.5 s | Missed. End to end, n=49 with 6 (run 42563147792, INCOMPLETE): p95 3766.67 ms (earlier n=20: 3010.04 ms). The capture call alone has p95 2718.84 ms per call (3 failed calls), which leaves no room for the truth check and writes. |
| hammer to SETTLED, 6 holds, p95 | 6 s | Missed. End to end, n=49 with 6 holds (run 42563147792, INCOMPLETE): p95 6927.43 ms (earlier n=20: 5591.30 ms, within 6 s). |
| handler 200, without the verify call | 300 ms | Met. Hosted route p95 112.03 ms (n=50, GitHub runner network included, so an upper bound; run 42558107791). Handler alone p95 1.07 ms (n=500, loopback). The verify call was not timed. |
The live judge walkthrough (judge smoke, simulated holds) passed all 17 steps, including the hammer, on 9 Nov 2026 (run 42584326641, manual dispatch, desktop profile). The earlier run after the Render redeploy (run 42561627128) passed steps 1 to 15 and 17, and step 16 (the console shows the lot as closed or sold) was fixed afterwards (issue #2208, PR #2209). The earlier smoke successes in the hosted report only loaded the landing page and are not journey evidence.
A of six holds is one truth check, one capture and five . 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 earlier end-to-end run (n=20) included the truth check and came in at 5591.30 ms p95, inside 6 s on that sample; the later n=49 run came in at 6927.43 ms p95, so the 6 s target is missed. The per-call p95 values of that run are order 1.23 s, authorize 1.54 s, capture 2.72 s and void 1.25 s, all above the 1 s per-call budget. Owner decision open: keep the targets, raise them with a reason, or reduce latency. Evidence: docs/evidence/latency.
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