Ping Monitor — Browser + Edge
Measure round-trip time from your browser (WebSocket/HTTP) and from the edge (Cloudflare Worker) for any IP/port. Compare latency, jitter, and loss across multiple targets.
Ping Monitor is built for the kind of network issues that are hardest to catch: intermittent spikes, short drops, and “it was slow for five minutes” reports. Instead of a single ping command, this page collects repeated samples and charts them so you can see trends—baseline latency, jitter (variance), and timeouts that count as loss.
What makes this monitor different is the comparison between measurements from your browser and from the edge (a Cloudflare Worker probe). If browser timings look bad but edge looks clean, you’re likely dealing with a local problem (Wi-Fi interference, VPN, last-mile). If both degrade at the same time, it’s more likely upstream congestion, routing changes, or an ISP event.
Parameter Guide — Total Pings: samples to collect per target (timeouts count). Interval: delay between batches (ms).
Batch Size: Edge IP only — per-call samples from the Worker. Timeout: per-sample timeout before counting as loss.
WebSocket: echo RTT via WS (e.g., wss://echo.websocket.events). HTTP: browser fetch timing (CORS may limit).
Edge IP: probe IP/host[:port] from Cloudflare’s edge via HTTP/HTTPS (not ICMP).
Jitter = std dev of successful RTT samples. Loss = timeouts / total attempts.
How to interpret the chart and stats
Avg is your baseline responsiveness. Max spikes often correlate with congestion, bufferbloat, or transient link issues. Jitter (standard deviation) matters more than average latency for real-time apps: high jitter causes choppy voice/video even when “Avg” looks acceptable. Loss counts timeouts, which usually indicates filtering, drops on a saturated link, unstable Wi-Fi, or a target that is intermittently unreachable.
When not to overreact: these measurements are not ICMP pings. Browser timing can be affected by DNS, CORS, TLS handshakes, or the remote server’s HTTP behavior. Some networks also treat certain traffic differently. That’s why the Browser vs Edge comparison is useful—if only one vantage point looks bad, focus your troubleshooting there.
Suggested workflow: 1) run this monitor during the problem window, 2) if you see spikes or loss, capture the timestamp, then 3) run Traceroute Map to find where the path inflates and check Outage Detector for upstream events. If the destination is a hostname and results differ across targets, validate resolution with DNS Checker.