Packet Loss Test — HTTP Probe Loss Estimator

ICMP echo request and reply is the classic packet loss tool. Many CDNs, cloud load balancers, and security-hardened origins drop ICMP while accepting TCP port 443 traffic. HTTP probes measure whether application-path packets complete TLS and return a response — a practical loss proxy when ping-test returns 100% loss but browsers reach the site fine.

This is an estimator, not a substitute for SPAN port analysis or router interface counters. Interpret results as reachability stability from our probe origin through to your target's HTTP stack.

We divide failed probes by total probes attempted. Failures include connection timeouts, DNS resolution failures, TLS handshake aborts, and TCP resets before a valid HTTP response. Successful probes receive any HTTP status code that completes transport — including 404 — because the path delivered packets.

Some operators prefer counting only 2xx as success. Our model treats transport completion as success to isolate network loss from application error semantics. Read per-probe rows when status-code policy matters for your SLO.

Probes originate from our hosting region, not your desk or every user city. Loss between your users and the target may differ entirely. A 0% result here does not guarantee zero loss worldwide — use latency-heatmap and multi-region monitoring for user-facing SLAs.

Compare results over time from this same tool to detect regression on the server-to-target segment rather than absolute global truth.

Higher probe counts smooth bursty loss — ten probes might show 10% loss from one unlucky timeout while fifty probes regress toward steady-state. Longer runs take more time and impose more load on the target — stay within authorized testing bounds.

For quick triage after deploy, a modest count suffices. For pre-change baselines, run longer series and record timestamps in change tickets.

Average latency across successful probes contextualizes loss. High loss with low latency on successes may indicate intermittent drops. High latency with zero loss may indicate congestion without outright failure — different remediation paths.

Pair with network-jitter-test when voice or real-time apps need stability metrics beyond mean loss.

WAF rate limits may return 429 or connection close after N rapid probes — inflating apparent loss without WAN packet drop. Maintenance pages returning 503 still count as transport success here. Read HTTP status in per-probe detail to distinguish policy blocks from network loss.

Retry after backoff when you suspect rate limiting rather than concluding the path is broken.

ping-test uses ICMP-style reachability where allowed. traceroute and mtr-path-analyzer expose hop-level behavior. This tool fills the gap when ping is blocked but HTTP should work — common on public websites behind strict edge policies.

Run all three on authorized infrastructure during post-incident reviews to build a fuller picture.

Probe only systems you own or have written permission to test. High-frequency probing of third-party sites may violate acceptable use policies and computer misuse laws. Our rate limits protect infrastructure but do not replace your compliance judgment.

Document authorization in internal change records when running repeated loss tests against production.

After DNS or CDN cutover, confirm HTTP reachability stability before closing tickets. When users report intermittent errors but ping is disabled, HTTP loss trends may still show drops. Baseline before firewall rule changes affecting port 443.

Export JSON results into incident timelines showing loss percent at specific UTC times.

Enterprise network performance monitoring deploys agents globally with ICMP, TCP, and synthetic transaction tests. This page offers a free single-origin HTTP estimator — excellent for quick checks, not replacement for ThousandEyes-class observability.

Combine with your vendor tools rather than relying solely on our probe path.