What should you monitor on a home or small network?

A useful home or small-business network monitor should cover more than device uptime. Monitor the local gateway, Internet quality, DNS, important services, Wi-Fi or link state, and endpoint health from the places where people actually use the network. Keep enough history to compare a normal period with the minutes before and during a fault.

That combination answers a much better question than "is the router online?": which layer changed, from whose point of view, and did anything else change at the same time?

The six layers worth monitoring

Layer	Useful signals	Typical question
Endpoint	CPU, memory, disks, uptime, network throughput	Is this device slow even though the network is healthy?
Local link	Wi-Fi signal and link rate, interface state	Is the problem between this device and the access point or switch?
Gateway	Reachability, latency, packet loss	Is the local network unstable before traffic reaches the Internet?
Internet path	Latency, packet loss, jitter, path diagnostics	Is the uplink degraded or has the route changed?
Name resolution	DNS response and correctness	Can the device find the service before trying to connect?
Application	TCP connect, TLS handshake, HTTP response	Is the network up while one service or protocol layer is failing?

You do not need every signal on every device. The value comes from having a few measurements that overlap enough to separate likely causes.

Start with a small target set

For each monitored location, begin with targets that represent different failure boundaries:

1. The local gateway. This separates a local-link or router problem from an upstream problem.
2. A stable public IP target. This tests the Internet path without depending on DNS.
3. A DNS resolver. Measure resolution separately from general reachability.
4. One service people actually depend on. Check the relevant TCP, TLS, or HTTP layer instead of assuming that an ICMP reply means the application works.
5. The endpoint itself. Keep local link and host-health signals where the platform permits them.

Choose public targets you are allowed to probe and use a conservative interval. More targets and faster checks are not automatically more informative. They can add noise, create unnecessary traffic, and make the important pattern harder to see.

Put measurement points where failures differ

Placement matters as much as the metric. A monitor beside the router can see the uplink well, but it cannot tell you what a laptop experiences through weak Wi-Fi in another room. A cloud monitor can see whether a public service answers from the Internet, but not whether a local DNS resolver or gateway is failing.

A practical arrangement is:

• One always-on point near the gateway. An OpenWrt router, small server, or NAS can preserve a continuous view of the location and its uplink.
• One point on an important user device. This exposes Wi-Fi, endpoint load, and local differences that a gateway-only monitor cannot see.
• One point per remote site. Offices, studios, family homes, or outbuildings need their own local perspective if their uplinks can fail independently.

NetTact uses this model directly: Agents run probes from each location and push the measurements to the Server. The Server does not dial into the Agents or run all probes from its own network.

Read groups of signals, not isolated numbers

One measurement rarely proves a cause. Correlated changes are more useful:

Pattern	Likely area to investigate next
Gateway latency or loss rises on one Wi-Fi device, but not on a wired device	That device's Wi-Fi link, interference, roaming, or access point association
Gateway stays stable while several devices lose the same public target	Router WAN, modem or ONT, ISP uplink, or upstream path
Public IP checks remain healthy while DNS checks fail	Local or configured DNS resolver, forwarding, filtering, or DNS transport
Network checks remain healthy while TCP, TLS, or HTTP fails	Target service, port, certificate, proxy, or application layer
Only one device is slow and host load rises at the same time	Endpoint resource pressure, local software, or interface saturation
Every site sees the same remote service fail	The remote service or a widely shared upstream dependency

Treat these as directions for the next test, not automatic proof. A router may rate-limit diagnostic traffic, a service may treat different protocols differently, and paths can be asymmetric.

Build a baseline before tuning alerts

There is no universal "good latency" number for every network. A nearby wired gateway, a satellite Internet path, and a remote office VPN have completely different normal ranges. First collect ordinary weekdays, busy periods, and idle periods. Then describe alerts in terms of user-visible behavior, for example:

• the gateway remains unavailable long enough to affect normal use;
• Internet latency stays well above this location's usual range;
• packet loss persists across several checks instead of appearing once;
• DNS repeatedly fails while basic Internet reachability remains healthy;
• an Agent stops reporting even though other devices at the site remain online.

This avoids alerting on one harmless spike while still preserving the spike in history for later diagnosis. NetTact's built-in availability and Agent-connectivity detection forms incidents from confirmed faults and keeps sub-threshold fluctuations as possible precursor evidence.

Keep enough history to diagnose intermittent faults

Live dashboards are useful during an outage, but intermittent problems often recover before anyone opens one. Retained history should make it possible to answer:

• Which endpoints and sites changed at the same time?
• Did gateway quality degrade before public targets failed?
• Did DNS fail independently of IP reachability?
• Did Wi-Fi or endpoint load change before the application became slow?
• Did the network path change, and when did recovery begin?

This is why a timeline that connects measurements, fault evidence, and recovery is more useful than a single red or green status.

Privacy and access boundaries

Monitoring software can see sensitive infrastructure details. Keep target scope intentional, expose no unnecessary Agent listener, and grant local collection capabilities explicitly. In NetTact, the Agent machine owns its collection and target-access policy; a Server can observe the grant but cannot enlarge it. Self-hosting keeps configuration, metrics, and incidents on infrastructure you operate.

Review the NetTact permission model before adding process, connection, or host-health collection. A basic network-quality deployment can start with a smaller permission set and expand only where the added evidence is useful.

A practical first deployment

For one location, start with one always-on Agent plus one everyday client device. Monitor the gateway, a stable public IP, the configured DNS service, and one important application. Let the baseline form, then use the guide to diagnose intermittent network problems when a real symptom appears.

NetTact Desktop is the quickest all-in-one start on one Windows or macOS computer. For several devices or locations, use the self-hosted Server deployment and enroll an Agent at each useful measurement point. An OpenWrt Agent can provide the always-on gateway perspective without requiring a separate machine.

Related standards

The IETF defines formal metrics for round-trip delay, one-way packet loss, and IP packet delay variation. A small network monitor does not need to reproduce a laboratory measurement system, but the definitions help keep latency, loss, and jitter from being treated as the same symptom.