How to Set Up a Ping Check (Step-by-Step Guide)
A ping check confirms that a server, network device, or any endpoint reachable on the internet responds to ICMP echo requests. It works at the network layer, so it does not care whether anything is listening on a specific port or serving web pages: it only confirms the host answers when pinged. That makes it a natural fit for routers, VPN gateways, load balancers, and any device you want basic up/down coverage on without configuring an HTTP or TCP check. If your target is a website or API and you need HTTP-level detail (status codes, response body, certificate health), an HTTP check is usually the better first choice; reach for ping when you want a lightweight, protocol-agnostic reachability test, or as a companion to another check type.
Url / Domain / IP
Enter the hostname, domain, or IP address you want to ping in the Url / Domain / IP field. You can also give the monitor a short, optional name; it's what shows up in alerts, reports, and any status widgets you embed, so a recognizable label (for example "core-router-fra" rather than the raw IP) is easier to scan later.
Main Settings

- Monitoring enabled: pauses or resumes the check without deleting it. Turn it off during planned maintenance so you don't get paged for a change you already know about.
- Interval schedule / Cron schedule: run the check on a fixed interval or on a cron expression. The interval slider runs from 1 minute up to 24 hours; drag it or type an exact value into the box on the right. Cron schedule swaps in a cron expression when you need a pattern the interval scale can't express.
- Tags: comma-separated labels (for example
infra, vpn) you can filter and search by across your monitor list. Purely organizational - they don't change how the check runs. - Full Log: saves every individual check result instead of grouping repeated identical results together. Turn it on for a complete history; leave it off to keep the check log smaller.
- Open Stats: makes this monitor's statistics and log page shareable with people who aren't logged in to your account. Don't enable it for anything you'd rather keep private.
- Attached monitors - DNSBL: runs a DNS blacklist check against the same domain on its own 12-hour schedule, independent of the ping interval above. A detected bad state notifies according to the Down/Repeat subscriptions in Alert Subscriptions, not the ping check's own events.
- Attached monitors - Web Risk: runs a Google Web Risk check against the domain for malware and phishing listings, also on its own schedule. It's gated by package - if your account doesn't include it, the toggle shows as unavailable.
Request Configuration

This section holds a single control, DNS Server Selection, and it only matters when your target is a hostname rather than a bare IP:
- Default DNS servers at locations: each monitoring location resolves your host using its own set of public DNS servers, so resolution follows the local regulations of that location, the same way it would for a real visitor there.
- Public DNS: resolves through a public DNS pool instead, with an optional list of excluded public DNS server IPs to skip specific resolvers.
- Custom: supply your own DNS server IPs, one per row - paste a comma-, space-, or line-separated list and it splits into rows automatically. The check then resolves your target through those servers instead of each location's defaults.
Public and Custom are package-gated; the screenshot above shows both locked behind an upgrade banner on this particular account. On a package that includes them, the dropdown works the same way, just without the lock.
Response Validation
Ping has no screenshot for this section, but it's still a full group in the monitor form, and it's what decides whether a check counts as passing.
By default, a check succeeds when at least one of four ICMP echo requests to the resolved address gets a reply. If the first resolved candidate doesn't answer, the check retries against up to two more DNS-resolved alternatives before it's marked failed - a domain backed by several A records can keep showing Up even if one of those addresses stops answering (see Troubleshooting).
- Expected IPs Validation: turn this on to additionally require that DNS resolves your host to one of a list of IP addresses you specify (one IPv4 or IPv6 address per row, same paste-splitting behavior as the custom DNS list above). If the host starts resolving somewhere else - DNS hijacking, a misconfigured record, an expired entry - the check fails even though something at the new address still answers pings. Leave it off if you don't need to pin the host to specific addresses.
Alert Subscriptions

- Subscribe all contacts to Up/Down events: a shortcut switch that subscribes every contact on your account to both Up and Down alerts for this monitor in one move.
- Down / Up / Repeat chips per contact: pick exactly which events each contact hears about. Down fires on a transition into a failing state, Up fires on recovery, and Repeat resends the Down notification on a schedule for as long as the monitor stays down, so a long outage doesn't go quiet after the first alert.
- Search contacts: filters the list by name or address.
Report Subscriptions

- Subscribe all contacts to Weekly/Monthly reports: subscribes every contact to both cadences at once.
- Daily / Weekly / Monthly chips per contact: choose which recurring uptime summary email each contact receives, independent of the real-time alerts above.
Monitoring Locations

- Location tree: pick which of HostTracker's monitoring locations run this check, by continent, country, or all world. The status column shows how many agents in each group are currently selected out of how many exist there. "Copy locations from another task" clones an existing monitor's location set instead of rebuilding it by hand.
- Search locations: filters the tree by name.
- Recheck strategy: controls how a state change gets confirmed before it's accepted. The default is a majority vote among the recheck locations. Alternatives: a specific number of locations confirming Down (slider from 1 up to 7, since the recheck pool draws from up to 7 locations); no recheck at all, so the first result is trusted immediately; full agreement across all recheck locations; or full agreement for Down while Up only needs a majority.
- If selected locations are unavailable: what happens when your chosen locations are temporarily offline. "Selected locations only" (the default) waits for one to come back rather than substituting data from elsewhere. "Closest locations" reruns the check from the nearest available locations instead. "Any location" falls back to any available location worldwide.
Worked example
Say you want basic reachability monitoring on an office VPN gateway that doesn't run a web server. Set Url / Domain / IP to the gateway's public IP and name it "hq-vpn-gateway". A bare IP has nothing to resolve, so leave Request Configuration on its default, and leave Response Validation on its default too - a single ICMP reply out of four attempts is enough to call it Up. In Monitoring Locations, pick two or three locations spread across regions so a local network blip near one of them doesn't trigger a false alert on its own, and leave Recheck strategy on the default majority vote. Under Alert Subscriptions, subscribe your ops contact to both Down and Up, and turn on Repeat so you keep hearing about it if the outage runs long. Add a Weekly report subscription if you want a recurring uptime summary alongside the real-time alerts.
Troubleshooting
- ICMP blocked, HTTP fine: many cloud providers and firewalls block ICMP echo by default while still serving HTTP/HTTPS normally, so a ping check can report Down for a site that is serving traffic. Either open ICMP on the target's firewall or switch to an HTTP or TCP Port check for that target.
- Expected IPs goes stale: if you turned on Expected IPs Validation and then migrated hosts or changed DNS providers, you'll see false Downs until the expected IP list matches the new addresses.
- Multiple DNS candidates can mask a single dead address: since the check retries against up to two more DNS-resolved alternatives before failing, a domain with several A records can keep showing Up even though one specific address stopped responding. Monitor the individual IPs directly, or turn on Expected IPs Validation, to catch that.
- No adjustable timeout: unlike some other check types, ping's per-attempt timing isn't a setting you can tune from this form. For more tolerance before an alert fires, use Recheck strategy in Monitoring Locations rather than looking for a timeout field that isn't there.
- A reply doesn't mean the service is healthy: it only tells you the device answers ICMP, not that anything useful is running on it. Pair a ping check with an HTTP or Port check on the same host to confirm the actual service is serving traffic.
Related
- Ping Monitoring - the product page for this check type.
- Free Ping Test - run a one-off ping without creating a monitor.
- Traceroute Monitoring - the natural next step when a ping check goes Down: see where the path breaks.
- Free Traceroute Tool - run a one-off trace instantly.
- Assertion Mode: Complete Response Validation Reference - the response-validation rule language used on other check types.
- Is the site down for everyone or just me? - the one-off version of the same question, run from outside your network.
- All monitoring guides - the setup guide for every other check type.