Ping tells you a machine is on the network. A port check tells you the service people actually use is alive. Knowing which question you are asking is the whole skill.
The video's starting point — a user with around forty devices to watch — is every office's problem: file servers, accounts PCs, network printers, the CCTV recorder, the Wi-Fi controller. Uptime Kuma gives you two simple weapons for all of them, the Ping monitor and the TCP Port monitor. Used carelessly they produce false alarms that teach everyone to ignore the system. Used properly, they catch real failures minutes after they happen. Here is the difference.
👆 Example values. Notice the mix: machines get ping checks, services get port checks — that pairing is the method, not a coincidence.
A ping monitor sends an echo request and waits for the reply. A reply proves the device is powered, cabled (or on Wi-Fi) and its network stack is alive. It does not prove the file shares open, the database runs or anyone can print. The bigger trap runs the other way: many Windows PCs block ping — the firewall's default behaviour on the Public network profile refuses echo requests, so a perfectly healthy PC shows DOWN all day. If a device “fails” ping from the moment you add it but works fine in person, do not declare it faulty: either allow ICMP echo in its firewall or, better, switch that device to a port check.
A TCP monitor connects to a specific port. If the connection succeeds, the actual service answered — far stronger evidence than a ping. The working set for a typical office (port numbers written out so nothing is ambiguous):
Rule of thumb: if people use a service on the device, monitor the service's port. Keep the ping monitor too — the pair together separates “machine dead” from “machine alive, service dead” at a glance.
Printers are the champion false-alarm generators. Most sleep aggressively: a sleeping printer may ignore ping for minutes, then wake instantly when a job arrives. One red minute at 2 PM is a sleeping printer, not a broken one — set retries higher on printer monitors and judge them by the pattern over days, not single blips. The port check on 9100 usually survives sleep better than ping, because the print engine stays reachable. NVRs and cameras are the opposite problem: they almost never sleep, so a red ping there deserves immediate attention — check power and the switch port before blaming the device.
Forty monitors named “New Monitor 1” through “New Monitor 40” are useless at 3 AM. Adopt a naming pattern on day one: place, device, check — for example Office - Printer 2nd Floor - TCP 9100. Use Uptime Kuma's tags for the groupings you think in: branch, department, critical. When the alert arrives it should read like a sentence a sleepy human can act on without opening anything.
Not every red row is equal. Set the accounts server and file server to brisk intervals and few retries — minutes matter. Let the guest-room printer check every five minutes with generous retries; its failure is a morning task, not a midnight phone call. Uptime Kuma lets every monitor carry its own interval, retries and notification choices, so build the urgency into the setup instead of relying on your mood when the alert lands.
Watch the video to see ping and network monitoring set up live for real servers — the same checks this guide explains.
▶️ Watch Full VideoAlmost certainly not. Printers sleep, and many stop answering ping while asleep yet print perfectly when a job arrives. Switch the printer to a TCP check on port 9100, raise its retries, and look at the pattern across a week before suspecting hardware.
Its firewall is blocking ICMP echo requests — standard Windows behaviour on the Public network profile. Either set the network profile to Private and allow echo, or monitor a real service port on that PC instead. The second option usually tells you more anyway.
Only if the machine running Kuma can reach them over the network — for example across a site-to-site VPN. Kuma sees the world from where it sits. If the VPN drops, every branch monitor goes red at once, which is confusing until you recognise the pattern: simultaneous failure usually means the path, not the devices.