Pingsivo · 1520 words · Updated 7 October 2026
English editorial adaptation prepared with AI assistance. Hypothetical examples are labelled. Technical sources accompany the relevant explanations.
A stability test observes repeated responses over time instead of reporting only one throughput result. Pingsivo's tool sends successive HTTP requests towards Cloudflare and plots successful timings and failed observations separately. It can reveal short-term irregularity on that path, but it cannot certify all-day stability, measure Wi-Fi signal strength or turn HTTP failures into packet-loss percentages.
When a graph is more useful than a speed number
If a call occasionally breaks up or a page sometimes pauses, a single download measurement may miss the symptom. A time series gives you a way to inspect what happened between headline values.
Start with a question: does the response become irregular in the office, during a backup, or at a particular time? The question determines the comparison. Avoid collecting graphs without recording what each run was intended to investigate.
The latency and jitter guide explains the difference between delay and variation. The Internet test page provides both throughput testing and a separate short stability observation.
What the HTTP observation records
The tool requests a small response from Cloudflare, records elapsed time and repeats at roughly one-second intervals where possible. Browser work and connection behaviour form part of the measurement. It is not an ICMP ping implementation.
A request that fails or reaches its deadline is recorded as an HTTP failure. The graph keeps that outcome distinct from a valid timing. Cloudflare receives your IP as part of the request, as with other direct requests to the service.
Successive observations do not necessarily start exactly one second apart. A slow request uses time, and browser scheduling may affect execution. Read actual timestamps and sample counts rather than assuming that duration always equals the number of points.
Choose a useful duration
Thirty seconds can provide a quick baseline. Sixty seconds gives a longer view of the same short-term scenario. Neither duration represents every period of the day or guarantees that an intermittent fault will occur during the run.
Keep the tab visible. Pingsivo interrupts the observation when the page is hidden to avoid silently comparing foreground and background browser scheduling. An interrupted observation remains partial and should be labelled accordingly.
Do not run the throughput test simultaneously unless you are deliberately conducting a separately defined loaded scenario. The interface prevents competing built-in measurements because the test traffic itself could change the result.
Read the curve point by point
First inspect the axes, units and duration. Then look for consistent regions, isolated peaks and failures. Compare those events with notes about household traffic, movement or application activity.
A peak identifies a slower response in this experiment. It does not name the responsible component. A red point identifies an unsuccessful HTTP observation, not a known number of lost packets. The packet-loss guide explains the distinction.
Keep the original graph or exported points. A screenshot cropped to remove the scale or completion status can become misleading when shared, even when the underlying measurement was valid.
Understand the summary
The median describes a central successful timing. The p95 is a high percentile of the successful sample; it is not the worst possible delay your connection can ever experience. Small sample sizes limit how broadly either number can be generalised.
The stability summary's variation uses changes between consecutive successful observations. It does not bridge a failed point as though the missing timing were known. Compare this calculation only with equivalent methods.
The failure count remains separate. Do not fill missing timings with zero or omit failed runs from a report that claims to describe reliability. A summary should retain enough context to make its exclusions clear.
Compare two situations carefully
Keep device, destination, duration and tool consistent. Change one condition, such as location or the presence of a controlled upload. Record unavoidable differences rather than hiding them.
A hypothetical graph that becomes irregular during an upload suggests investigating loaded conditions. It does not establish the precise location of a queue. Read the loaded-latency guide before interpreting that pattern.
For location comparisons, follow the Wi-Fi and Ethernet protocol. Repeat a pattern before spending money or changing several settings at once.
Export an observation with context
The JSON export preserves points and summary information. Add your notes about device, location, declared connection and concurrent activity without replacing original values.
Write a limited conclusion: what was observed, what the method cannot establish, and what you will check next. “Responses varied during this upload” is more defensible than “the router is definitely faulty”.
After a correction, repeat the original scenario and verify the actual application. A cleaner short graph is useful evidence, but the purpose is to improve the experience that prompted the investigation.
Plan a short observation that someone else can repeat
Choose one scenario and describe it before pressing start. For an office problem, note the desk position, device, declared connection and whether ordinary work applications are open. Select thirty or sixty seconds and retain that duration for the comparison. If you later change the duration, treat it as a differently scoped observation rather than silently mixing the summaries. This simple preparation makes the exported points more useful because another person can understand what you tried to observe and what remained uncontrolled during the run.
The browser should stay visible throughout the collection. If an incoming call or another task forces you to leave the page, allow the run to be labelled interrupted. Do not try to turn the partial record into a full-duration result by adding empty points or repeating the final value. The partial record may still contain useful evidence, but its duration and completion state must remain attached. A graph's attractive appearance is less important than an accurate account of how the points were obtained.
In a hypothetical comparison, the first run is quiet and the second occurs while a permitted background upload is active. The observer records when that upload begins and whether the actual application becomes difficult to use. If the HTTP curve changes, a third observation can check whether the pattern returns after the upload is paused. The sequence supports investigation of activity-related changes without claiming to locate a router queue or establish a packet-loss percentage. Keep the transfer scenario separate from the built-in throughput test's own loading phases.
Inspect the raw timings when a summary looks surprising. A central value may remain similar even though the number of high observations changes. Failed requests can also reduce the set of successful points used for timing summaries. This is why the sample count, failure count and graph belong together. Do not choose the median alone because it makes the connection look better, or the highest point alone because it makes an incident look more dramatic. The aim is a balanced description of the short period observed.
For comparison screenshots, keep the axis labels visible and explain whether scales differ. A graph automatically fitted to its data can make a modest variation look visually large, while a broad scale can make an important change look small. Numeric summaries and exported points help readers check the visual impression. If you draw another chart in a spreadsheet, preserve the missing values and do not connect through failures as though an actual timing had been observed at that point.
End the record with the next question. Perhaps you need to repeat near the router, compare a permitted wired path, or examine the application's own statistics. A short stability test is most effective as one step in a controlled investigation. It is not a substitute for all-day observation when the complaint concerns a different period, and it should not be advertised as permanent monitoring. Keeping that boundary clear lets users benefit from the graph without drawing stronger conclusions than a minute of HTTP observations can support.
If a later graph looks cleaner, check that the duration, scale, destination and conditions remain comparable before announcing improvement. A shorter sample can simply miss an intermittent event. Record that limitation and verify the actual activity that prompted the test. The strongest practical conclusion combines a repeatable measurement change with an observed improvement in the relevant task, while retaining uncertainty about periods and applications outside the experiment.
FAQ: short stability tests
Does one minute establish that my connection is stable?
No. It describes one short sample towards one destination. Repeat at relevant times and check the actual application before making a broader claim.
Why are there fewer points than seconds?
Requests take time, may reach a deadline, and depend on browser scheduling. The tool records actual observations rather than fabricating one point for every elapsed second.
Can I run the speed test at the same time?
The built-in controls prevent simultaneous runs. Throughput traffic would change the conditions of the stability observation. Loaded-latency testing should be interpreted as a distinct scenario.
Why does switching tabs stop the test?
Background execution can change timing behaviour. Stopping makes that interruption explicit rather than silently mixing observations collected under different browser conditions.
Do red points mean lost packets?
No. They mean failed HTTP observations. Packet loss requires a suitable measurement method; it cannot be calculated directly from these red points.