Know whether your public server responds

Choose the right signal

Ping can fail because ICMP is blocked while a TCP service remains available. A successful TCP connection shows the port accepted a connection; it does not prove the application transaction works.

Public infrastructure, no agent required

Check public hosts and ports from the monitoring service. CPU, memory, disk, containers and private-network agents are outside the current product.

Match the check to the service

Use Ping when ICMP reachability is the question and TCP when a public service should accept a connection on a configured port. An accepted connection is a narrow signal: it does not verify application authentication, a database query or a customer transaction.

Follow failures with application evidence

If Ping fails but TCP succeeds, inspect ICMP policy before concluding the service is down. If TCP is refused, confirm the service is listening and review firewall or routing changes. Add HTTP or API assertions when you need to validate the actual response rather than only a network connection.

Keep the boundary clear

This product observes public destinations from the monitoring service. Private network checks, host CPU and memory, server agents, containers and Kubernetes telemetry are outside this phase. These checks do not scan subnets or discover arbitrary open ports.

Connect infrastructure and service ownership

Use explicit dependencies for known upstream relationships and keep monitor history independent from alert suppression. Assign actionable destinations and maintenance windows. Correlated failures can guide investigation, but timing alone does not establish that the server caused an application outage.

Common questions

Related guidance

• Run a public Ping test
• Track reachability
• Assert application responses
• Model alert dependencies