ProbeOps
HomeToolsServicesPricingDownloadsHorizonAboutContact Us
Login/Sign Up

About Latency Test

Test network latency and round-trip time from 6 global probe locations. Measure connection latency, TCP handshake time, and network path efficiency.

Measure network round-trip time from multiple global probe locations. Identify connection latency and network bottlenecks.

Key Features

  • Multi-region latency testing
  • Time to First Byte (TTFB)
  • Connection time measurement
  • DNS lookup time
  • Historical comparison

How Latency Test Works

ProbeOps Latency Test tests from 6 global locations to provide comprehensive results. When you run a check, our probe nodes in US East (Virginia), US West (Oregon), EU Central (Helsinki), AP South (Mumbai), CA Central (Canada), AP Southeast (Sydney) simultaneously query the target to identify regional differences and ensure global accessibility.

Results are returned in real-time with detailed breakdowns per region, allowing you to identify location-specific issues that might affect your users in different geographic areas.

Common Use Cases

  • Check if a website is down for everyone or just you
  • Monitor uptime from multiple geographic locations
  • Measure response times and TTFB globally
  • Identify regional outages affecting specific users

Related Tools

You might also find these ProbeOps tools useful for your diagnostics:

Specialized Variants

ProbeOps offers specialized versions of Latency Test for specific use cases:

  • Website Response Time Test - Measure HTTP response time (not bandwidth) from multiple global locations. Test full request lifecycle from connection to response.
  • TTFB Checker - Measure server processing time—how long until the server starts responding. Isolate backend performance from network latency.

API Access

All ProbeOps tools are available via REST API for automation and integration. The Latency Test can be called programmatically from your applications, CI/CD pipelines, or monitoring scripts. See our API documentation for integration guides.

Pricing

Latency Test is available on all ProbeOps plans including our free tier. Free users get 100 probes per month with access to 2 regions. Paid plans starting at $19/month include unlimited regions and higher limits. See pricing details.

Network Latency Test

Measure network round-trip time from multiple global probe locations. Identify connection latency and network bottlenecks.

What This Checks
Multi-region latency testingTime to First Byte (TTFB)Connection time measurementDNS lookup timeHistorical comparison

About Latency Test

Test network latency and round-trip time from 6 global probe locations. Measure connection latency, TCP handshake time, and network path efficiency.

Key Features

Multi-region latency testing

Time to First Byte (TTFB)

Connection time measurement

DNS lookup time

Historical comparison

Also Available via API & MCP Server

Automate latency test checks in your CI/CD pipelines or run them directly from your AI coding agent.

REST API

Single endpoint, JSON response. Integrate into any language or platform.

cURL

curl -X POST https://probeops.com/api/v1/run \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"tool": "latency_test", "target": "example.com"}'
Learn more about the API

MCP Server

Works with Claude Code, Cursor, Windsurf, and any MCP-compatible IDE.

Claude Code

> Check the latency test for example.com

Claude uses the probeops_latency_test tool to run
the check from 6 global regions and returns
structured results.
Learn more about the MCP Server

Network latency measures the round-trip time (RTT) for data to travel from our probe servers to your target and back—this is fundamentally different from page load speed or bandwidth. High network latency causes delays before any data even begins transferring, affecting everything from API calls to real-time applications.

Our network latency test measures connection-level timing from 6+ global probe locations: TCP handshake time, connection establishment, and round-trip delays. This reveals network path efficiency and geographic performance differences that CDN configuration or server placement can address.

For complete performance analysis, combine network latency testing with TTFB checking to isolate server processing time, and uptime monitoring to ensure availability. Use traceroute to identify which network hops are adding latency.

**Methodology:** TCP connect timing from 6 probe regions measuring DNS lookup, TCP handshake, and connection establishment separately.

Common Errors & How to Fix Them

Click to expand troubleshooting steps

What This Means

The server encountered an unexpected condition. This is a generic error when the server crashes or has a configuration problem.

How to Fix

1) For users: wait and retry—often temporary. 2) For site owners: check server error logs (tail -f /var/log/nginx/error.log), verify file permissions, check .htaccess for syntax errors, test PHP/application code locally.

500internal server errorserver crashserver down

What This Means

The server acting as a gateway received an invalid response from the upstream server. Common with reverse proxies, load balancers, and CDNs.

How to Fix

1) For users: wait 5-10 minutes and retry. 2) For site owners: check if upstream service is running (systemctl status nginx php-fpm). 3) Verify proxy_pass configuration. 4) Check upstream server logs. 5) Increase proxy timeout values if requests are timing out.

502bad gatewayproxy errorupstream

What This Means

The server is temporarily unable to handle the request due to maintenance or overload. Usually temporary.

How to Fix

1) For users: wait and retry—often means scheduled maintenance. 2) For site owners: check server resources (htop, free -m). 3) Scale up if overloaded. 4) Check if maintenance mode is accidentally enabled. 5) Review rate limiting settings.

503service unavailablemaintenanceoverloaded

What This Means

The gateway server didn't receive a timely response from the upstream server. The upstream server is too slow or unresponsive.

How to Fix

1) For site owners: increase timeout values (proxy_read_timeout in nginx). 2) Optimize slow backend code/queries. 3) Check database performance. 4) Add caching layers. 5) Test: curl -I -m 30 https://example.com to check response time.

504gateway timeouttimeoutslow server

What This Means

The server didn't respond within the expected time. Could be server overload, network issues, or firewall blocking.

How to Fix

1) Check if server is reachable: ping example.com. 2) Test specific port: nc -vz example.com 443 -w 5. 3) Check from different location (VPN/proxy). 4) For owners: verify firewall allows traffic (ufw status), check server resources, ensure service is running.

timeoutconnection timeoutno responseunreachable

What This Means

The server actively rejected the connection. The service isn't running on the expected port, or a firewall is blocking it.

How to Fix

1) Verify service is running: systemctl status nginx (or apache2, etc.). 2) Check listening ports: netstat -tlnp | grep 443. 3) Verify firewall: ufw status, iptables -L. 4) Check if correct IP/hostname: dig example.com A. 5) Try alternate port if applicable.

connection refusedrefusedservice not running

What This Means

Could not establish a secure connection. Certificate may be expired, invalid, or there's a protocol mismatch.

How to Fix

1) Check certificate: openssl s_client -connect example.com:443 -servername example.com. 2) Verify expiry: echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -dates. 3) Check TLS version support. 4) For owners: renew certificate, check intermediate chain, verify SNI configuration.

ssl errorcertificate errorhttps errorsecure connection

What This Means

The domain name couldn't be resolved to an IP address. Domain may not exist, DNS servers may be unreachable, or there's a configuration error.

How to Fix

1) Verify domain exists: whois example.com. 2) Check DNS: dig example.com A @8.8.8.8. 3) Try different DNS server: dig example.com A @1.1.1.1. 4) Flush local DNS cache. 5) For owners: verify NS records at registrar, check DNS provider status.

dnsresolution faileddomain not foundnxdomain

Frequently Asked Questions

Common questions answered

A website is considered "down" when it cannot be reached or fails to respond to requests. This can mean the server is offline, overloaded, misconfigured, or there's a network issue preventing access. Our tool checks from multiple global locations to determine if the site is down for everyone or just you.

is-it-downbasics

When a website works for others but not you, common causes include: your ISP blocking the site, DNS cache issues on your device, local network problems, or geographic restrictions. Our multi-region checker tests from 6+ locations worldwide to definitively answer whether it's down globally or just for your location.

is-it-downtroubleshooting

200 means success—the site is up. 403 means access forbidden (you're blocked). 500 is an internal server error. 502 (Bad Gateway) means the server got an invalid response from an upstream server. 503 (Service Unavailable) means the server is temporarily overloaded or down for maintenance. 504 is a gateway timeout.

is-it-downhttp-codes

A site might be accessible in one region but down in another due to CDN issues, regional server failures, DNS propagation delays, or geographic blocking. Multi-region checking gives you the complete picture. If a site is down in only some regions, it often indicates CDN or load balancer problems rather than a complete outage.

is-it-downregions

For critical sites, set up automated monitoring that checks every 1-5 minutes. For occasional checks, using this tool when you notice issues is sufficient. ProbeOps offers scheduled monitoring that can alert you via email, Slack, or webhook when your sites go down—before your users notice.

is-it-downmonitoring

Try these steps: 1) Clear your browser cache and cookies, 2) Flush DNS cache (ipconfig /flushdns on Windows, sudo dscacheutil -flushcache on Mac), 3) Try a different browser or incognito mode, 4) Restart your router, 5) Try a different network (mobile data), 6) Use a VPN to test from another location.

is-it-downtroubleshooting

Related Tools

View All Tools →
TracerouteIs It DownPort Checker

Specialized Versions

Website Response Time TestMeasure HTTP response time (not bandwidth) from multiple global locations. Test full request lifecycle from connection to response.
TTFB CheckerMeasure server processing time—how long until the server starts responding. Isolate backend performance from network latency.

Global Infrastructure Verification

Verify SSL certificates, DNS records, and connectivity from 6+ regions worldwide.

Get Started Free
Last updated: January 27, 2026