Ping Monitoring

Find out whether a host is reachable at all, how fast it answers, and how much of your traffic to it is being dropped — the network-level check that sits underneath everything else.

What is a ping monitor?

A ping monitor asks one question on a schedule: is this machine reachable, and how long does it take to answer? There's no status code, no page content, no certificate — just reachability and latency.

Example: "gateway.example.com should always answer. If the box itself disappears, page me."

This is the check for the layer below your application. A website monitor tells you your app returned a 500; a ping monitor tells you the server it runs on stopped existing. Those are different pages at 3am, and they lead to different fixes.

One thing to know up front, because it changes how you read your results. Enori decides reachability TCP-first: every check opens a TCP connection, and a real ICMP echo (an actual ping) runs as the fallback when TCP can't get through. That order is deliberate — ICMP is blocked or rate-limited across huge parts of the internet, so a pure-ICMP monitor would report half the healthy internet as down. Checking TCP first means the monitor keeps working on hosts that drop ping entirely, and the ICMP path is still there for hosts that answer ping but expose no TCP service at all.

The packet-loss option adds real ICMP echoes to every check, so you also get a genuine loss percentage — not a TCP-connect success rate dressed up as one.

When to use one

• Machines without a web service. Routers, switches, firewalls, VPN concentrators, NAS boxes, jump hosts, IoT gateways, game servers — anything with an IP address and no HTTP endpoint worth checking.
• Separating "the host is gone" from "the service is gone". This is the highest-value use. Run a ping monitor and a port monitor on the same machine: both Down means the box is gone, only the port Down means the box is fine and the service crashed. That distinction saves real diagnostic time.
• Latency and packet-loss tracking to a specific host. A link that's degrading — a saturated uplink, a flapping route, a failing NIC — shows up as rising latency and loss long before anything goes hard-Down.
• Checking the network path to something you don't control. An upstream provider, a partner's API host, a payment gateway's edge — when you want evidence about the path, not the application.

When to use something else

The honest limitation: ICMP is blocked more often than you'd think

This is the thing most likely to surprise you, so it's worth stating plainly.

Huge numbers of hosts do not answer ping. Default AWS security groups drop ICMP. Most cloud firewalls, corporate edge firewalls, CDNs and DDoS-protection layers drop or heavily rate-limit it. Many hosts that do answer treat ICMP as the lowest-priority traffic on the box, so its latency is not representative of anything your users experience.

What that means for you, concretely:

• A ping monitor still works on an ICMP-blocked host — as long as the host accepts a TCP connection on port 443, 80, or a port you name. That's the common case and it's why TCP runs first.
• A host that blocks ICMP but answers TCP will show close to 100% packet loss if you turn packet-loss measurement on, while being perfectly healthy. The reachability verdict is unaffected — but the loss number is measuring the firewall, not your network. Don't set a loss alert threshold on a host you haven't confirmed answers ping.
• A host that blocks ICMP and exposes nothing on 443 or 80 is the wrong target for a ping monitor. Give it a port monitor on a port it actually answers on, or set the optional Port field (below) so the ping monitor's TCP probe aims somewhere useful.

If you're not sure whether your host answers ICMP, run ping from your own machine before enabling loss measurement. Two minutes there saves a week of confusing amber.

How it works

Every check, Enori:

1. Resolves your hostname to an IP address and screens it. Private, internal, loopback and reserved addresses are refused — Enori checks from the public internet, so it can only monitor what the public internet can reach.
2. Opens a TCP connection. To the port you set, if you set one — otherwise it tries 443, then 80. The first port that answers wins.
3. Falls back to a real ICMP echo if no TCP port answered — three echo requests, up to 2 seconds each.

What counts as Up:

• A TCP connection succeeded, or
• The host answered at least one ICMP echo.

A connection that's actively reset by the host also counts as Up: a reset proves a live machine answered you, which is exactly what this monitor is asking about. Because a reset comes back near-instantly and would drag your latency chart down, it's recorded with a response time of 0 ms rather than its true sub-millisecond value.

What counts as Down:

Response time is whichever probe answered: the TCP connect time, or — when TCP failed and ICMP carried the check — the average round-trip time across the successful echoes. A check that found nothing at all records no response time, so failed checks never distort your latency chart.

Worth knowing: because TCP usually answers first, your latency chart is normally a TCP connect time, not a ping RTT. It's a genuine, useful measure of network round-trip to the host — just not the same number ping prints on your laptop. Turn on packet-loss measurement if you want true ICMP round trips recorded alongside it.

One resolved address, screened in full

If your hostname resolves to several addresses, Enori screens every one of them before checking anything. If any of them is a private or reserved address, the whole check is blocked — a split-horizon DNS setup, or a stray internal A record left on a public name, will stop the monitor rather than quietly checking one of the public addresses.

Otherwise the check uses the first address the resolver returned. On a host with both IPv4 and IPv6 that can differ between checks, and ping monitors have no IP-version selector — if you need to pin the check to one stack, use a port monitor, which does.

Literal IP addresses are accepted in the host field, IPv4 and IPv6 alike.

Where your checks run from

Ping checks run from Enori's probe regions — real machines in the locations you can pick in the wizard — and this matters more for ping than for other monitor types: genuine ICMP is only possible from those probes. If no probe is reachable for a check, Enori falls back to running it from its own infrastructure so you still get a verdict; on that path the TCP probe works normally but no packet-loss figure is recorded (it's left blank rather than reported as zero or as total loss).

The wizard shows every region; the ones whose fleet isn't live yet are marked Coming soon.

How often it checks

You pick the interval when you create the monitor — 1 minute through 24 hours, defaulting to 5 minutes. A 30-second interval is available as an add-on.

While a monitor is Down, Enori re-checks it every 30 seconds regardless of your configured interval. You don't need a tight interval to learn quickly that something came back — recovery is picked up within half a minute either way.

Setting one up

Go to Monitors, click Add Monitor, and pick Ping. The wizard has two steps — Type and Configure — and everything below is on the Configure step.

Screenshot: the Ping option on the monitor-type picker (step 1).

1. Monitor Name (required)

Whatever you'll recognise in an alert at 3am. e.g. "Edge router — Frankfurt".

2. Group (optional)

Put related monitors together, or leave it ungrouped.

3. Hostname or IP (required)

A bare hostname or IP address — example.com, 192.0.2.10, or an IPv6 literal. No scheme, no path, no port.

Private, internal and reserved addresses are rejected when you save.

4. Port (optional)

Leave this empty and Enori tries 443, then 80 — the right choice for almost every host, because nearly everything answers on one of them.

Set it when your host doesn't. The field accepts 1 to 65535, and the wizard suggests the case it's for: a database, a game server, an appliance's management port — anything where 443 and 80 are closed but something else is listening. e.g. 3306 for MySQL, 5432 for Postgres, 27015 for a game server.

Two things to know before you use it:

• A named port makes this monitor overlap with a port monitor. If what you actually care about is "is this service accepting connections", the port monitor is the better tool — it can assert on the service's reply, and it's editable afterwards. Use the ping monitor's port field when you want host reachability and 443/80 simply aren't available.
• The port can't be changed later from the interface. It's set at creation only; the edit dialog for a ping monitor doesn't show it. Editing anything else leaves it intact, but changing it means recreating the monitor (or using the API). Get it right the first time.

Screenshot: the Ping Configure step with the host filled in and the Port field left empty.

5. Measure packet loss (optional)

A checkbox, off by default. Turning it on sends real ICMP echoes on every check and records a loss percentage alongside your latency.

This is worth its own section — read Measuring packet loss before you enable it, particularly the part about hosts that don't answer ping.

6. Packet-loss alert threshold (optional — appears only when measurement is on)

A percentage from 0 to 100. Leave it empty to record loss without ever alerting on it, which is the right starting point on a host whose ICMP behaviour you haven't confirmed.

7. Primary Region

Where your monitor runs its checks from. Regions whose fleet isn't live yet are marked Coming soon, and Automatic picks one for you based on the host.

Below it, Multi-region verification — a second region re-checks a failure before you're alerted, so one bad network path doesn't page you. It's always on for Base; Pro can turn it off; Business can also choose which regions do the verifying.

8. Check Interval

Defaults to 5 minutes. Options run from 1 minute to 24 hours; 30 seconds requires the add-on.

9. Alert settings

Below the divider on the same step:

• When to alert — how many consecutive failures before you're notified: First failure, 2, 3, or 5. Defaults to 2 consecutive failures, which absorbs a single flaky check.
• Notify me via — which of your alert channels to use.
• Repeat Alerts — whether to keep reminding you while it stays Down.
• Alert on slow response — an optional latency alert. See Alerts below.

Then click Create Monitor. Enori queues a first check immediately, so you normally see a result within seconds.

Measuring packet loss

Packet loss is the metric that tells you a network path is degrading rather than broken. A host at 30% loss is usually still "Up" — connections succeed eventually — while everything running over that path is timing out, retrying, and feeling broken to your users. Reachability monitoring alone will never show you that.

Tick Measure packet loss and Enori sends real ICMP echoes on every check and records the percentage that went unanswered.

What the numbers actually mean

Each measurement sends 3 packets. That's the whole reason the numbers look the way they do:

There is nothing in between. A threshold of 20% and a threshold of 33% behave identically — both first fire at 33%. Set your threshold with those four values in mind rather than picking a number that feels precise.

Loss does not decide Up or Down

This is the key difference from every other alert on this page, and it's deliberate.

Reachability is still decided by TCP. Packet loss is measured alongside the verdict, never as part of it. A host at 100% loss that still accepts TCP connections is Up, and its uptime percentage, SLOs and reports are all unaffected.

A packet-loss alert is a warning about quality, not an outage. It arrives through your normal alert channels, but it doesn't open an incident and it doesn't dent your uptime numbers.

How the alert fires and clears

Once you set a threshold:

That last row is why loss occasionally shows as blank rather than 0%: "not measured" and "no loss" are different facts, and Enori won't report one as the other. Loss goes unmeasured when a check ran from Enori's own infrastructure rather than a probe (see where checks run).

Choosing a threshold

• Start with no threshold at all. Enable measurement, watch the monitor for a day or two, and see what the host's normal reading is. Then set a threshold above it.
• On a host that answers ICMP normally, 33 is a sensible first alert — it means at least a third of packets are vanishing, which is well past "a bit of jitter".
• On a host you haven't confirmed answers ICMP, set no threshold. If it blocks ping, every check reads 100% and any threshold pages you forever about a healthy machine. The measurement itself is harmless; the alert is not.
• Don't bother below 33. Anything from 1 to 33 fires at exactly the same moment.

Screenshot: the Ping Configure step with packet-loss measurement enabled and a threshold of 33.

Reading the results

The Ping detail page shows the standard monitor view — current status, uptime, response-time chart, recent checks — plus a Host Details panel labelled TCP & ICMP reachability.

Recent Checks lists each check with its result, response time, and — on a failure — the exact error message. That message is the fastest route to a cause; see Troubleshooting. You can export the list to CSV.

Screenshot: a Ping detail page with the Host Details panel showing a resolved IP, last latency and a non-zero packet-loss reading.

Changing a monitor later

Open the monitor and click Edit. You can change:

• Host / IP Address
• Measure packet loss and its threshold
• Timeout (seconds) — 1 to 120, default 30
• Check interval, name, group, tags
• Alert settings — failure threshold, channels, repeat alerts, latency alert
• Primary region and multi-region verification

The Port field is not editable. It's set when you create the monitor and preserved untouched by later edits, but the edit dialog doesn't show it. To change or clear a port, recreate the monitor or use the API.

You can pause a monitor at any time from its detail page — checks stop, alerts stop, and the paused period can be excluded from your SLOs. Resuming takes a plan slot again, so if you're already at your plan's monitor limit you'll need to free one or upgrade first.

For planned work, use a maintenance window instead of pausing: checks keep running and keep their history, but alerts and incidents are suppressed and the window is excluded from your uptime figures.

Alerts

Ping monitors use the same alerting as every other monitor type — channels, escalation policies, on-call schedules, maintenance suppression. See the Alerts guide for the full picture.

Three distinct things can notify you:

Slow response is configured in the alert settings as Alert on slow response — a threshold in milliseconds (100–30,000, default 1,000) evaluated across the last 10, 20, 50 or 100 checks (default 20). Because it uses P95 rather than a single reading, one slow check won't trigger it. It's genuinely useful on a ping monitor: rising round-trip time to a host is often the first visible symptom of a saturated link.

Each alert type sends its own recovery notification when conditions return to normal.

FAQ

Is this a real ping, or a TCP connect?

Both, in that order. Every check tries TCP first, and a real ICMP echo runs when TCP can't get through. Enable packet-loss measurement and real ICMP echoes run on every check regardless, so you get genuine round-trip data alongside the TCP verdict.

The TCP-first design is what lets the monitor work on the very large share of hosts that drop ICMP entirely.

My host answers ping from my laptop but shows 100% packet loss. Why?

Almost always because the ICMP is being dropped somewhere between our probes and your host rather than at your host itself — a cloud firewall, a security group, an edge filter, or ICMP rate-limiting that kicks in for traffic from outside your network. Your laptop is probably inside a network path that permits it.

Check the reachability verdict: if the monitor is Up, the host is fine and the loss figure is measuring a firewall. Either allow ICMP from the public internet, or turn the loss threshold off and keep measurement on for information only.

Why is my response time 0 ms?

The host reset the connection instead of completing it. That still proves the machine is alive — which is what this monitor asks — but a reset returns almost instantly, and recording that time would make your latency chart meaningless. It's stored as 0 ms to keep the chart honest.

Why does packet loss sometimes show nothing at all?

Because that check couldn't measure it — it ran from Enori's own infrastructure rather than a probe, which is where genuine ICMP is possible. Enori records "not measured" rather than pretending it was 0% or 100%, and the alert logic skips those checks entirely so a gap can't fire or clear an alert.

Does packet loss affect my uptime percentage?

No. Reachability is decided by TCP; loss is measured alongside it. A host at 100% loss that still accepts connections is Up, and your uptime, SLOs and reports are unaffected. Only Down checks count against uptime.

Why can't I set a 10% packet-loss threshold that actually means 10%?

Each measurement is 3 packets, so the only possible readings are 0, 33, 67 and 100%. Any threshold from 1 to 33 fires at 33%. The threshold field accepts 0–100 for future flexibility, but those four values are what you're really choosing between today.

Can I monitor a host on my private network?

No. Enori checks from the public internet, so private, internal and reserved addresses are rejected when you save. If the hostname resolves to several addresses and any one of them is private, the check is blocked entirely — worth knowing if you run split-horizon DNS.

Can I force IPv4 or IPv6?

Not on a ping monitor. The check uses whichever address your host resolves to first, which on a dual-stack host can vary between checks. If pinning the version matters, use a port monitor — it has an explicit IP-version setting.

Should I use a ping monitor or a port monitor?

Ping for "is this machine there", port for "is this service working". They answer different questions and the best setup for an important host is both — when both go Down the machine is gone, when only the port goes Down the machine is fine and the service died.

How quickly will I hear about an outage?

Your check interval plus your failure threshold. At the defaults — 5 minutes and 2 consecutive failures — roughly 10 minutes. Tighten the interval for hosts where minutes matter. Recovery is always spotted within 30 seconds, because Down monitors are re-checked on that cadence regardless of their interval.

Can I manage ping monitors through the API?

Yes — see the API reference and the MCP server. The same rules apply: a port, if you send one, must be 1–65535, and packet-loss settings are accepted only on ping monitors with a threshold between 0 and 100.

Troubleshooting

"Ping failed: TCP port(s) 443, 80 and ICMP all unreachable"

Nothing answered on either path. The host is genuinely unreachable, or everything is being filtered.

1. Check the machine is up by any other route you have.
2. Check whether anything listens on 443 or 80. Plenty of healthy hosts don't — a database server or an appliance may have neither. Set the optional Port field to a port it does answer on, or use a port monitor instead.
3. Check the firewall. A security group that allows only your office IP range will produce exactly this, because our probes come from elsewhere.

"Ping failed: … ICMP unavailable on this host"

The wording is about our side, not yours: this check ran somewhere that couldn't send ICMP, so only the TCP result stands — and TCP failed. Treat it as the case above and work the TCP path. If it persists, contact support with the monitor name.

"DNS resolution failed" or "DNS resolution timed out"

The hostname doesn't resolve from the public internet, or resolution took longer than 5 seconds.

1. Confirm it resolves publicly — dig @8.8.8.8 rather than through your own resolver, which may have internal records yours doesn't.
2. Check for a typo, and for a name that only exists in internal DNS.
3. Check your nameservers are healthy. A DNS monitor on the same name will tell you directly.

The host resolves fine but the monitor is blocked

The name resolves to a private, internal or reserved address — and remember every resolved address is screened, so one internal record among several public ones blocks the whole check. Look at what the name returns publicly and remove or correct the internal record, or point the monitor at a genuinely public name.

Packet loss is stuck at 100% but the monitor is Up

Your host isn't answering ICMP, but it is accepting TCP connections. The reachability verdict is correct and the loss figure is measuring a firewall rather than your network. Either permit ICMP echo from the public internet, or clear the alert threshold and keep the measurement for information.

Packet loss readings are missing on some checks

Those checks ran from Enori's own infrastructure rather than a probe region, where ICMP measurement isn't possible. Nothing is wrong with the monitor, and the gaps can't trigger or clear a loss alert. Persistent gaps across many hours are worth reporting to support.

The monitor went Down during a deploy on our side, but nothing was wrong

Check whether the host stopped accepting TCP on 443 and 80 during the window — a load balancer draining, a service restarting, a firewall rule reloading will all do it. For planned work, wrap it in a maintenance window: checks keep running and keep their history, but alerts and incidents are suppressed and the window is excluded from your uptime figures.

Reference: limits and defaults

Related documentation

• Port monitoring — for checking a specific service rather than the host
• DNS monitoring — for watching records rather than reachability
• Alerts — channels, escalation policies and on-call rotas
• Maintenance windows — suppress alerts during planned work
• SLOs — reliability targets and error budgets
• Uptime reports — exportable uptime and SLA reports
• Monitoring IP addresses — where our checks come from, and firewall allowlisting
• API reference and MCP server — programmatic management

Feedback or corrections: support@enori.io