The simplest monitor there is, done carefully: every device with an address is pinged by the SmartTile monitoring engine, directly or from inside the site tunnel, and a real outage becomes one ticket for the location in the IT Service Management (ITSM) system your team already uses — with an uptime figure that never claims more than the monitor saw.
check_icmp every 7–9 min (faster for devices given a shorter clock), 2-min retries ×3 to confirm DOWN. The alert engine reads it every 60 s; after the ticket gate (15 min default, per-device override) a live re-ping confirms and one ticket opens per location; recovery sends the restored e-mail.Most false tickets come from ping monitors that trust one lost packet, and most missed outages from graphs that quietly stop. SmartTile's ping path is built against both: DOWN only after the engine's own retry cascade and the ticket gate, a live re-ping before any ticket, and an uptime figure cross-checked against the recorded state history.
Each device gets a host check and a PING_Reachability service: 5 echoes per check, warning at 80 % loss or 3 s, critical at 100 % or 5 s. Status is synced into SmartTile every 120 s.
Packet loss and round-trip time are stored for every monitored device. At 100 % loss the latency is null, never 0 ms — a dead host never draws a healthy flat line.
Each UP→DOWN and DOWN→UP is written to the device's state history with its loss and RTT. After a restart, an outage that began while SmartTile was down is recorded at the engine's own change time.
RFC 1918 and CGNAT targets are pinged from the server's site-tunnel source address. A device whose Monitoring Route names a jump host is pinged from that host over SSH.
After the ticket gate, a live ping (3 echoes, 6 s deadline; ~10 s via a jump host) must fail too. The engine vetoes any ticket for a device it read UP in the last 10 minutes.
Down devices at a site share one ticket, with each new device added as a note — opened in Rev.io and fanned out to the company's connected ITSM system. Recovery posts a note and the restored e-mail.
The Uptime modal (24 h → 1 year) reads the ping RRDs, then cross-checks the recorded state history: when the graph is thin, stale or optimistic, the lower figure wins and the modal says why.
The RRD Integrity agent scans every monitored device's ping files each night — frozen files, heartbeats too short, uptime disagreeing with history — and e-mails what it finds.
| Setting | Default |
|---|---|
| Check interval | 7–9 min (7 + device id mod 3), retry 2 min, 3 attempts |
| Packets / thresholds | 5 · warn 80 % or 3000 ms · crit 100 % or 5000 ms |
| Alert e-mail / ticket | 15 min / 15 min platform-wide; per-device override |
| Fast clock | On: a device set below the default is polled fast enough to meet its own clock |
| The moment | A plain ping monitor | With SmartTile |
|---|---|---|
| One lost packet | Red tile, maybe a ticket. | Nothing yet: 3 attempts, 2 min apart, before the engine calls it DOWN. |
| A real outage | Someone opens a ticket by hand. | DOWN recorded → alert e-mail at the device's clock → after the ticket gate a live re-ping fails → one ticket for the location. |
| Three more devices at the same site drop | Three more tickets. | Added to the open location ticket as a note. |
| It comes back | Ticket left open. | Recovery confirmed, note posted, restored e-mail sent; the ticket closes per the company's close policy. |
| The graph file breaks | 100 % uptime on a dead device. | Uptime falls back to state history and the modal shows a data warning; the nightly agent reports the file. |
check_icmp -H <ip> -n 5public targetscheck_icmp -H <ip> -s <tunnel ip>private / VPN targetscheck_ping_remote <ip> <jump host>ping from the jump host over SSHping -c 3 -w 6 <ip>live confirm before a ticketstatus.dat → devicesstatus, loss, RTT every 120 snagiosgraph RRD (rta, pl)Uptime modal seriesNo agent, no credential. The only change on your side is allowing echo-request from SmartTile's monitoring address.
Uptime, latency and outage history are served only for devices on the signed-in user's locations.
A snoozed device is re-checked against the database before any ticket is opened or reopened, so a maintenance window set mid-cycle still holds.
Lazy ping gate, engine-UP veto, fast clock, uptime honesty and per-device timings each have a platform switch — instant rollback.
| Objection | Answer |
|---|---|
| “Ping is too noisy to ticket on.” | Three engine attempts, a 15-minute gate you can change per device, a live re-ping and an engine-UP veto sit between a lost packet and a ticket. |
| “Our devices are behind the firewall.” | Private targets are pinged from the site tunnel or a jump host — the same path SNMP and SSH use. |
| “We can't ping this box at all.” | Turn ICMP off: SNMP or the vendor's API becomes the monitor, and the alert and ticket path is the same. |