Ping monitoring: host reachability without fetching a web page
Sometimes you care that a host answers on the network, not that nginx returns 200. ICMP ping checks round-trip reachability—useful for routers, bastions, or internal endpoints exposed for ping.
Ping vs HTTP uptime
HTTP monitors exercise application stacks; ping checks whether the target responds to ICMP at all. They answer different questions.
When ping is the right tool
Firewalls may block ping while HTTP still works—or the opposite. Choose the probe that matches what “up” means for that asset.
Alerts and timelines
Ping failures create incidents with the same notification channels as other monitors—email, Telegram, webhooks.
Pairing with DNS and SSL monitors
Routing or TLS issues may surface as HTTP errors before ping fails; combine probes when you own the full stack.
Limits of ICMP
Many cloud endpoints block ICMP; HTTP or TCP-based checks may be the only viable external signal.
Relation to heartbeat monitors
Heartbeats prove a job completed; ping proves a host answered—complementary, not interchangeable.
What SitePuls does not do
Traceroute analytics, packet loss histograms for ISPs, or on-prem agents inside your LAN—synthetic checks run from SitePuls infrastructure to reachable targets.
Next steps
If HTTP checks already cover user-visible paths, add ping only where network reachability is the contract you need to watch.
What you can verify with SitePuls here
- Ping monitors let you set the TCP port used for reachability (commonly 443 for HTTPS hosts).
- By default the scanner uses a TCP connection to your configured port; some deployments can enable ICMP first with TCP fallback, depending on server configuration.
- Checks follow your interval plan and create incidents on sustained failures like other monitor types.
- Combine ping monitors with HTTP monitors when you want both socket reachability and full HTTP behaviour.
Where incident alerts can go
- Email addresses saved as alert contacts receive messages when incidents open or resolve (according to your notification settings).
- Telegram notifications via the SitePuls bot after you link a chat to an alert contact (including the bot /start flow for pending contacts).
- HTTPS webhooks that receive JSON with event type, monitor identifiers, status, timestamp, optional incident id, and a short message for generic integrations.
- Slack-compatible incoming-webhook formatting: alert contacts can use a dedicated mode so payloads match Slack-style incoming webhook expectations.
FAQ
Can ping replace website monitoring?
No. Ping does not validate HTTP status, TLS, or page content—use HTTP monitors for web properties.
Why would ping fail but HTTP work?
ICMP may be filtered while TCP/443 is open, or an upstream path may drop only ICMP.
What interval can I use?
Intervals follow your plan limits, same as other monitor types.
IPv6 targets?
Configure monitors for the hostnames or addresses your stack resolves and that SitePuls can reach.
Private networks?
SitePuls must reach the target over paths you expose—there is no in-network agent.
Combine with API monitoring?
Yes—ping for host reachability, REST monitors for application behavior.
Does ping measure latency for SLA?
Round-trip time may be visible in monitoring data; SLA-style reporting in the product focuses on incidents and configured targets where available.
Where do I add a ping monitor?
Create a monitor and select the ping/ICMP type in the SitePuls UI, then set interval and contacts.