Ping

Ping is a free tool that checks whether a website, server, or port responds and reports timing, status, or error information.

Which ping method should I use?

Choose HTTP(s) for a website, API, or web service, Ping (ICMP) for basic server reachability, and Host / Port for a service listening on a specific network port.

The word "ping" can describe several different checks. Traditional ping uses the Internet Control Message Protocol, or ICMP, to ask a host for a reply. It can show that a machine is reachable, but it does not confirm that a website, database, or mail service is working.

An HTTP or HTTPS check contacts a web address and can return an HTTP status code. This is usually the more useful choice when a page will not load or an API appears unavailable. A host-and-port check asks whether a service can be reached at a numbered port, such as an SMTP server on port 25 or a database on its configured port.

• Use URL with HTTP(s), including the scheme, such as https://www.example.com/status.
• Use Host with Ping (ICMP), such as server.example.com.
• Use Host and numeric Port with Host / Port, such as mail.example.com and 25.

Reading the server check report

Read the reachability result first, then use the timing, HTTP status, and error details to identify what kind of failure occurred.

• Ping Server identifies the ping server associated with the reported check.
• Online is one possible reported result.
• Offline is one possible reported result.
• Response time shows how long the check took from the tool's server. It is not a measurement from your browser, office, or home network.
• Response status code is the HTTP response code returned by a website or web service. The 2xx class indicates success, the 3xx class indicates that further action is needed to complete the request, the 4xx class indicates a client error, and the 5xx class indicates a server error.
• Error provides failure information when the check cannot complete normally.

A web server can respond quickly with a 500 status code, which means the responding server encountered an unexpected condition that prevented it from fulfilling the request. A 401 or 403 response can show that the web endpoint exists even though it requires authentication or refuses access. The status code and error remain useful diagnostic details.

Troubleshooting examples

A useful check starts with the same endpoint and protocol involved in the reported problem. These examples use reserved or illustrative domain names, so they describe the expected result format rather than a current live result.

1. A website stops loading after a DNS change. Select HTTP(s) and enter https://www.example.com. The report will show an up or down result, response time, and an HTTP status code or error.
2. Outbound email is not being delivered. Select Host / Port, enter mail.example.com as the host, and enter the SMTP port configured by the mail provider, commonly 25, 465, or 587. A successful port response shows that the service is reachable from the checking server. It does not send a message, verify login credentials, inspect a mailbox, or confirm that another mail server will accept a particular email.
3. An API returns errors after a deployment. Select HTTP(s) and enter a public health or status endpoint such as https://api.example.com/health. A 5xx response indicates a server error, while a connection error indicates that the connection was not established.

For a browser certificate warning, an HTTPS check can help establish whether the endpoint responds from another network location. It is not a complete certificate audit. Use SSL Lookup when you need certificate names, dates, or chain details, and HTTP headers lookup when redirects or response headers may explain the behavior.

Why can the check disagree with what I see locally?

The check can disagree because it runs from a server rather than from your device.

DNS records have a time to live, usually called TTL, that tells recursive resolvers how long they may cache an answer. After an address change, one resolver may still return the old address while another already returns the new one. This is commonly described as DNS propagation, although much of the delay comes from cached records expiring at different times.

Local differences can also come from a browser cache, operating-system DNS cache, VPN, proxy, firewall, content delivery network, or geographic routing. An ICMP check may fail because a firewall blocks ICMP while HTTPS continues to work. The reverse can happen when the machine responds to ICMP but the web service is stopped or listening on a different port.

If a recent DNS edit is involved, compare results over time and check the authoritative DNS records. Whois Lookup can help identify domain registration and nameserver information, but it does not prove that every resolver has refreshed its cache.

What should I verify before acting on a failed result?

Verify the input format, selected protocol, destination port, and recent DNS or firewall changes before treating a failed result as proof of an outage.

• Include http:// or https:// in a web URL and check that the hostname, path, punctuation, and capitalization are correct. URL paths can be case-sensitive on some servers.
• Enter only the hostname where the form asks for a Host. Spaces around a hostname are not part of a valid DNS name.
• Use digits for Port and confirm the service's configured port rather than assuming its conventional one.
• Remember that punctuation and percent-encoding in a URL can change the requested resource. An encoded space is written as %20, while an unencoded space does not belong in a normal URL.
• Under IDNA, an internationalized label can have a Unicode U-label form and an ASCII A-label form; applicable A-labels begin with xn--. Support for automatically converting accented or non-Latin names is not specified, so the DNS-compatible form is the safer diagnostic input.

When the result is unexpected, copy the exact public URL or hostname from the affected service and confirm it independently from another network.

Common questions about Ping checks

Does a redirect status mean the website is broken?

No. A 301, 302, 307, or 308 response commonly sends the client to another URL. Check the destination and watch for redirect loops, an incorrect hostname, or an unexpected move from HTTPS to HTTP.

Can this check reach a private IP address on my local network?

Private addresses such as 10.0.0.0/8 and 192.168.0.0/16 are not routed across the public internet. Because this tool runs on its server, it should not be treated as a test from inside your office or home network. Use a local command-line ping, curl request, or port-testing utility for an internal-only service.

Is the hostname or URL stored?

The input travels to the server over HTTPS because the check is performed there. According to the tool's privacy rule, the input is not stored. Do not include passwords, API keys, session tokens, or other secrets in an HTTP(s) URL submitted to Ping.