Connection Stability: Look Beyond a Single Number
A quick speed or ping result describes a short window. Repeated observations can reveal changes that an average hides. This monitor records browser HTTP request durations over a fixed time, plots the latest 90 completed requests and keeps statistics for the full run. Use the same region and run length for a more useful before-and-after comparison.
What This Test Measures — and What It Cannot
The target is the AWS DynamoDB regional API endpoint you select, shown above before testing. It is a public HTTP endpoint, not your current game's match server. Each sample is a HEAD request: the timer ends when the browser resolves fetch after response headers arrive, without downloading a response body. DNS lookup, connection reuse, TLS, browser scheduling and server processing can affect the result. It is not an ICMP ping or a direct measurement of game latency.
HTTP jitter is the mean absolute difference between adjacent successful response-time samples in this run. Failed or timed-out samples break that sequence. At least two adjacent successful samples are required. Mean response time and the slowest response use successful samples only; an unavailable value is shown as a dash.
HTTP request failure rate is failed requests plus timeouts, divided by all completed requests. A request times out after 2.5 seconds and is cancelled. A browser fetch rejection is also a failed request. Manually cancelled requests, requests cancelled when you leave the page, and an unfinished request at the run limit are excluded. Because these requests use no-CORS mode, the browser does not expose their HTTP status codes; a completed request does not prove that the API returned a successful status.
The HTTP monitor does not count UDP, ICMP or game packets. A 0% HTTP failure rate does not prove zero packet loss. HTTP failures can arise from connectivity, DNS, browser restrictions, endpoint conditions or other causes. To investigate packet loss in a game, compare the game's own telemetry or a network diagnostic suited to the relevant destination and protocol.
Read how our tests work for our measurement methods and their limits.
Compare Runs Without Changing Everything
- Choose a nearby region, note its exact endpoint and start a 1 minute run.
- Keep the tab visible. The monitor stops when the tab is hidden, the page is left or the browser reports that it is offline.
- For an intermittent issue, repeat with a 3 or 5 minute run. The run still stops automatically at its selected limit.
- Change one condition, such as switching from WiFi to Ethernet or pausing a background upload, then repeat using the same region and duration.
- Compare the full-run response-time variation and request failures. A cleaner result is an observation for this endpoint and test window, not a diagnosis or gaming readiness grade.
Read our guide to jitter versus ping and connection troubleshooting guide for online gaming for context. If only one game or service has problems, investigate that service's route and telemetry too.
Frequently Asked Questions
Does this test measure actual packet loss?
No. It records timed browser HTTP requests to a selected AWS regional API endpoint. Failed requests and timeouts are HTTP observations, not a percentage of lost UDP, ICMP or game packets. A 0% HTTP failure rate cannot prove that your game has no packet loss.
How is HTTP jitter calculated?
The result is the mean absolute difference between consecutive successful HTTP response-time samples in this run. A failed request or timeout breaks the pair, so the calculation does not bridge an unavailable sample. At least two adjacent successful samples are needed; otherwise the result is unavailable.
How long should I run a stability test?
Choose a 1, 3 or 5 minute run. Each run stops automatically at its selected limit. Use the same region and duration when comparing WiFi with Ethernet or testing another time of day. A clean short run does not rule out intermittent problems outside that window.
What happens if I change tabs or lose connectivity?
The test stops and cancels its active request when the tab becomes hidden, the page is left or the browser reports that it is offline. Manual Stop also cancels the request. It never resumes automatically; choose Start Test for a fresh run when you are ready.