Ping

Ping is a free tool that checks whether a website, server, or port is reachable and reports its response time, status code, or error.

What does a ping check actually test?

A ping check determines whether a remote system responds from the network where the check is run. The exact test depends on the protocol you select.

• HTTP(s) checks a web URL over HTTP or HTTPS. It is suitable for websites, APIs, and web services because it can return an HTTP response status code.
• Ping (ICMP) checks whether a host responds to Internet Control Message Protocol echo traffic. This is the conventional networking meaning of "ping".
• Host / Port checks whether a specific network port is reachable on a host. Common examples include an SMTP mail server, a POP server, or a database endpoint.

These checks answer slightly different questions. An ICMP response shows that a host accepts and responds to that type of network traffic, but it does not prove that its website or mail service works. An HTTP response provides a status code, which may indicate a problem. A successful port check shows that the port is reachable, not that an application-level login or database query will succeed.

How do I use Ping?

Select the appropriate Ping Protocol, enter the corresponding address, and run the check. Use the type of input expected by that protocol.

1. Choose HTTP(s) and enter a complete URL, such as https://www.example.com/status, when troubleshooting a website, API endpoint, or web service.
2. Choose Ping (ICMP) and enter a Host, such as server.example.com or an IP address, to check whether a server responds to ICMP traffic.
3. Choose Host / Port, enter the Host, and then provide the numeric Port. For example, an SMTP submission service commonly uses port 587, while HTTPS commonly uses port 443.

Do not add a URL path to a host-only check. By contrast, an HTTP check may require the full path if the problem affects a specific API route or page rather than the entire domain. Transport port numbers use 16-bit values from 0 to 65535. Port 0 is reserved and is not normally used as a service port. Spaces, commas, and labels such as "port 443" are not part of a port number.

The Ping check runs on the server. Your Ping input is sent to that server over HTTPS and is not stored. Avoid including passwords, API keys, or other secrets in a URL because URLs may expose them to the remote service and through other parts of normal web infrastructure.

How do I interpret the ping result?

Check the availability result first, then use the response time, HTTP status, or error result to narrow down the problem.

For example, a hypothetical HTTP result might show Up!, a response time of 180 ms, and status code 200. A 200 status code indicates that the request succeeded. A 404 response means that the origin server did not find a current representation for the target resource or is unwilling to disclose that one exists. A 5xx (Server Error) response belongs to the Server Error class. The exact cause depends on the specific status code.

A Down! result does not always mean the entire machine is offline. A firewall may block ICMP while HTTPS continues to work, or one port may be closed while other services remain available. Run the check that matches the service users are trying to reach.

Common problems ping can reveal

If a website does not load, start with HTTP(s) and the exact affected URL. If the domain responds but one page returns 404, check the route, rewrite rules, or deployment. If HTTPS produces a certificate warning in a browser, use SSL Lookup for certificate details instead of relying on ping alone. HTTP headers lookup can also show redirects and response headers.

If email does not arrive, use Host / Port with the mail server hostname and the port configured in the sending or receiving application. A reachable SMTP port does not prove that the server accepts a specific message. Authentication failures, spam filtering, DNS mail records, and recipient policies are beyond the scope of a basic port check.

After moving a site to a new host, check its hostname with ICMP or HTTP as appropriate. Verify the DNS record and allow for cached answers. Whois Lookup may help confirm domain registration information, but it does not show which DNS answer every resolver currently has.

Why can DNS caching make a correct result seem wrong?

DNS caching can temporarily cause the tool's server and your own device to resolve the same hostname to different addresses. Recursive resolvers retain DNS answers according to their time to live, often called the TTL, and some applications or operating systems also maintain local caches.

"Propagation" is commonly used to describe this delay, although DNS records do not spread everywhere through a single coordinated process. Each cache expires on its own schedule. As a result, a recently changed record may work on one connection while another still uses the previous address.

Because this tool runs the check on its server, the result reflects that server's network path and DNS view at that time. It cannot prove that every UK broadband provider, mobile network, or corporate resolver sees the same destination. Compare the result with a local check and query the relevant DNS records when location-specific behavior matters.

Frequently asked questions

What happens if a domain name contains accented or non-Latin characters?

IDNA converts eligible Unicode domain labels to ASCII A-labels. Punycode is the encoding algorithm used within relevant A-labels. Browsers often convert the readable spelling automatically, but host fields and diagnostic systems may require the A-label form. Check the spelling carefully because visually similar Unicode characters can refer to different domains.

Will a low response time always stay low?

No. Response time varies based on routing, network congestion, server load, and physical distance. Record several checks at comparable times, and investigate sustained changes rather than treating a single slow response as proof of a problem.

Before changing DNS, firewall, or server settings, confirm that you checked the exact hostname, URL path, and port used by the affected service. Save the time of the result and compare it with local logs so you can match both sides of the connection.