Latency

Latency is how long a supplier takes to answer a request, measured from your side of the connection. The average is the easiest number to report and the least useful one: it hides the slow tail that users actually wait for. Track percentiles (p50, p95, p99) and the share of requests that hit your timeout.

Why the average misleads

Suppose 100 searches go to a supplier. 90 come back in 400 ms and 10 take 8 seconds.

• The average is (90 × 400 + 10 × 8,000) ÷ 100 = 1,160 ms. It looks acceptable.
• The median (p50) is 400 ms. Half of the searches are fast.
• The p95, the time within which 95% of requests finish, is 8,000 ms, and so is the p99 (8,000 ms).

One search in ten takes eight seconds. On a results page that waits for every supplier, those requests set the speed of the whole page. The average describes a request that never happened.

Which percentiles to watch

• p50 (the median) shows the typical experience and is stable from day to day. Use it to spot gradual drift.
• p95 is the working number for most supplier reviews. It captures the slow tail without being dominated by a handful of outliers.
• p99 shows the worst experiences. It is noisy at low volume, so read it over enough requests to be meaningful.

Percentiles cannot be averaged across suppliers or periods. Compute them from the raw response times, or from histograms built for that purpose.

Timeouts change what you measure

Every integration has a timeout. When a request exceeds it, you stop waiting, and that request usually disappears from latency statistics and reappears as an error. Two consequences follow:

1. Tightening a timeout makes latency look better and error rates look worse, with no change on the supplier side.
2. A supplier that is slow for some requests can look fast in latency reports while quietly losing you results.

Report latency and timeout rate side by side, and note the timeout value with every report so that numbers from different periods are comparable.

Measure each step separately

A search, a price re-check and a booking are different operations with different costs and different tolerances.

• Search runs in parallel across suppliers, so its slow tail decides the speed of the results page.
• Price check or pre-book happens once the user has chosen. Users tolerate a short wait, but a slow answer here often comes with a price change.
• Book can legitimately take longer. It must never be cut short by an aggressive timeout: a booking that times out may still have been made. Treat it as unknown and reconcile it with the supplier before retrying.

Request shape matters as well. Multi-room, large-occupancy and wide-area searches are slower for most suppliers. Compare like with like before concluding that one supplier is slower than another.

Where the time goes

Latency measured on your side includes your own network path, TLS setup, serialization and any queueing in your connector. If one supplier is slow from every location and at every hour, the cause is likely on their side. If it is slow only at peak times or only from one data centre, look closer to home first: connection pooling, keep-alive settings and payload compression are common culprits.

How APIPulse scores it

APIPulse takes one latency figure per supplier and rates it Fast, Moderate, Slow or Very slow against the selected thresholds. Enter the average for a quick check, or the p95 for a stricter one, and keep the same choice over time so that periods stay comparable. If you switch to p95, raise the thresholds to match; see Thresholds.