Ping
What this ping tool does
This page offers three probe styles: an HTTP(s) check that measures end-to-end web or API reachability, a classic ICMP ping for raw host liveness (when the network path allows it), and a host and port TCP connect for database, mail, or custom service ports. You get a pass or fail style result plus timing where available. It is meant for quick smoke tests from this server infrastructure, not a replacement for full synthetic monitoring with probes in multiple regions.
When to use it
Use HTTP mode after deploy to confirm the load balancer returns 200 or your expected status code. Use ICMP when you only care if the machine answers at the IP layer but firewalls may block echo requests anyway. Use host/port when SSH or Postgres suddenly refuses connections even though the VM console looks fine. Always correlate with DNS Lookup if hostnames changed and SSL Lookup if HTTPS fails after a cert rotation.
Worked example
Users say the marketing site is down. Choose HTTP(s), paste https://status.example.com/health, and read the status code and latency. If that passes but the main marketing URL fails, you have an application or routing issue, not total packet loss. If ICMP fails but HTTP passes, your ICMP may be administratively prohibited while the app still works.
Frequently asked questions
Why does ICMP fail but HTTP works?
Many cloud security groups block ICMP while allowing 443. That is normal; switch modes instead of assuming total outage.
Is response time from my browser?
No. It is measured from this service's execution environment to your target. Your users sit elsewhere; use RUM or multi-region probes for their reality.
Can I test UDP?
This UI focuses on TCP connect for custom ports. Stateless UDP requires different tooling.
Does a green check prove SLA?
It proves reachability at one instant. Feed results into your incident timeline; they are not a contractual uptime certificate.