Monitoring alert: devices stopped reporting — how to find the cause
For customers who got an alert that some monitored devices have stopped reporting. This runbook helps you quickly tell whether the issue is a real device outage, an agent/service problem, a network block, or a monitoring-side delay, and gives concrete steps to fix each one.
TL;DR — If your monitoring provider says some devices stopped reporting, the most common cause is that the monitoring agent (the small service that sends health data) stopped running or lost network access to the provider. Start with the provider dashboard to see whether the affected devices share the same site, network, or operating system, then check the agent service status on one affected device and confirm it can reach the provider over HTTPS. Reading time: ~6 min
The scenario
It is a normal Tuesday afternoon and you get an email from your monitoring provider: "5 devices stopped reporting." Nothing else looks obviously broken yet. Users are not complaining, but your security or operations contact wants to know whether this is a real outage, a network issue, or just a delayed heartbeat (a regular "I'm alive" check-in). You open the monitoring dashboard and see several devices marked offline, but they are spread across one office and a couple of cloud servers.
Symptoms
- Monitoring dashboard shows devices as "offline", "not reporting", or "last seen X minutes ago"
- Alert email or webhook text similar to:
Device stopped reporting
Host has not checked in for 15 minutes
Last heartbeat received: 2026-10-30 13:42 UTC
- On one affected machine, the monitoring/agent service shows stopped, failed, or restarting repeatedly
- Local logs may show messages like:
connection timed out
TLS handshake failed
temporary failure in name resolution
failed to send heartbeat
context deadline exceeded
- If the whole site is affected, multiple devices behind the same office firewall or VPN stop reporting at nearly the same time
- If the provider has a status page, it may show ingestion delay, agent outage, or degraded API performance
Likely causes
| Cause | How common | Quick check |
|---|---|---|
| Monitoring agent service stopped or crashed | Very common | In your device management tool or local services panel, check whether the monitoring/agent service is Running |
| Network egress blocked to the monitoring provider | Very common | From one affected device: curl -I https://your-monitoring-provider.example.com |
| DNS resolution failure on the device/network | Common | From one affected device: nslookup your-monitoring-provider.example.com |
| Device clock drift broke TLS | Common | Compare device time to a known-good clock in the OS date/time settings |
| Provider-side ingestion delay or outage | Occasional | Open your provider's public status page in a browser |
| Device actually offline, asleep, or disconnected | Occasional | In your RMM/control panel or hypervisor/cloud console, check power/network state |
Step-by-step diagnosis
-
Check whether the affected devices have something in common.
In your monitoring provider's dashboard, filter the alert list by site, network, device group, or operating system. If all affected devices are in one office, one VPC (private cloud network), or one OS family, that points to a shared cause. If they all line up by location/network, jump to Fixes → Network egress blocked or Fixes → DNS resolution failure. -
Rule out a provider-side delay first.
Open your provider's public status page in a browser. If it shows ingestion delays, API degradation, or agent check-in issues, this is likely your problem. Jump to Fixes → Provider-side ingestion delay or outage. -
Confirm whether the device itself is actually up.
Use your normal control panel first: your cloud console, hypervisor, MDM (mobile device management), or RMM (remote monitoring and management) tool. Check whether the device is powered on and has network connectivity. If the device is off, suspended, or disconnected, jump to Fixes → Device actually offline, asleep, or disconnected. -
Check the monitoring agent service on one affected device.
If you have remote desktop access, use the OS UI first:- Windows:
Servicesapp → find the monitoring/agent service → Status - Linux with a control panel: your server panel's Services page
- If you have shell access:
- Windows:
systemctl status monitoring-agent
or on Windows PowerShell:
Get-Service | Where-Object {$_.Name -match 'agent|monitor'}
If the service is stopped, failed, or restarting in a loop, this is your problem. Jump to Fixes → Monitoring agent service stopped or crashed.
- Test basic HTTPS reachability to the provider.
From one affected device:
curl -I https://your-monitoring-provider.example.com
If you get a timeout, connection refused, or cannot connect, this points to a firewall, proxy, VPN, or outbound filtering problem. Jump to Fixes → Network egress blocked to the monitoring provider.
- Test DNS resolution.
From one affected device:
nslookup your-monitoring-provider.example.com
If you see errors like server can't find, NXDOMAIN, or temporary failure in name resolution, DNS is the problem. Jump to Fixes → DNS resolution failure on the device/network.
- Check the device clock.
On the device, open Date & Time settings and compare it to a trusted clock source. If you have shell access:
date -u
If the time is off by more than a few minutes, TLS (encrypted HTTPS) can fail and the agent may stop reporting. Jump to Fixes → Device clock drift broke TLS.
View as text
[Monitoring Provider]
^
| 4. HTTPS heartbeat
|
[Firewall/Proxy] <---- 3. DNS ---- [DNS Resolver]
^
|
| 2. outbound 443
|
[Device]
|
| 1. agent service
v
[Local OS/Service Manager]Fixes
Monitoring agent service stopped or crashed
Restart the service, then check whether it stays up.
- Windows: open
Services→ right-click the monitoring/agent service →StartorRestart - Linux:
sudo systemctl restart monitoring-agent
sudo systemctl status monitoring-agent --no-pager
- To see recent errors on Linux:
journalctl -u monitoring-agent -n 50 --no-pager
If the service fails immediately after restart, look for config errors, expired credentials, or disk-full messages in the logs.
Verify it worked:
systemctl is-active monitoring-agent
Expected output:
active
Network egress blocked to the monitoring provider
If devices in one office or one network segment stopped reporting together, check the firewall, proxy, VPN, or outbound filtering rules.
- In your firewall or secure web gateway dashboard, allow outbound HTTPS to the provider's documented endpoints on port
443 - If you use an explicit proxy, confirm the agent is allowed to use it or bypass it for the provider domain
- Quick retest from the device:
curl -Iv https://your-monitoring-provider.example.com
If your environment uses a local firewall on Linux:
sudo ufw status
If you use Windows Defender Firewall, open Windows Security → Firewall & network protection → Allow an app through firewall and confirm the agent is allowed.
Verify it worked:
curl -I https://your-monitoring-provider.example.com
You should get an HTTP response line, not a timeout.
DNS resolution failure on the device/network
Point the device or network back to a working DNS resolver, then retest.
- In your router/firewall dashboard, check the configured DNS servers
- On Windows, renew DNS and clear cached bad answers:
ipconfig /flushdns
ipconfig /renew
nslookup your-monitoring-provider.example.com
- On Linux with
systemd-resolved:
resolvectl status
resolvectl flush-caches
nslookup your-monitoring-provider.example.com
If the configured DNS server is unreachable, replace it in your network settings or DHCP (automatic network settings) scope with your intended resolver.
Verify it worked:
nslookup your-monitoring-provider.example.com
You should see an IP address returned.
Device clock drift broke TLS
Correct the device time and re-sync with NTP (network time protocol, the standard time-sync service).
- Windows:
Settings → Time & language → Date & time → Set time automatically → Sync now - Linux with timedatectl:
sudo timedatectl set-ntp true
sudo timedatectl status
If the clock is far off inside a VM (virtual machine), also check the hypervisor time-sync setting in your VM platform.
Verify it worked:
date -u
curl -Iv https://your-monitoring-provider.example.com
The TLS handshake should complete without certificate date errors.
Provider-side ingestion delay or outage
There is usually nothing useful to "fix" on your side while the provider is degraded.
- Confirm the incident on the provider status page
- Pause or mute duplicate alerts in your incident process if your tooling allows it
- Keep one affected device under observation and avoid mass restarts unless the provider specifically advises it
- If the provider asks for evidence, collect one timestamp and one sample error from an affected device:
curl -Iv https://your-monitoring-provider.example.com
Verify it worked: the provider status page returns to normal and affected devices begin updating last seen again.
Device actually offline, asleep, or disconnected
Bring the device back online.
- In your cloud console or hypervisor, start the VM or reconnect the network adapter
- For laptops/desktops, wake the device and confirm it has internet access
- For remote sites, ask someone onsite to confirm power and link lights on the switch/router
⚠️ Restarting a production server can cause downtime. If the device hosts a live application, confirm with your change process before rebooting it.
If a reboot is approved and needed:
sudo reboot
Verify it worked: the device appears online in your normal management tool and the monitoring dashboard updates its last seen time.
Prevention
- Alert on agent service health, not just missing heartbeats. Add a local service check for the monitoring agent so you can distinguish "agent dead" from "network path broken." Example on Linux:
systemctl is-active monitoring-agent
- Monitor DNS from each site. Add a scheduled check from one device per office/VPC:
nslookup your-monitoring-provider.example.com
Alert if it returns no address.
- Pin time sync in your build images and server templates. For Linux images, enable NTP by default:
timedatectl set-ntp true
- Document outbound allow-lists for security controls. Keep the provider's required domains and ports in your firewall change record so a future rule cleanup does not silently block reporting.
- Add a "same-site blast radius" view in your incident process. When multiple devices stop reporting, first group by office, VPC, VPN, or OS. This reduces false escalation and gets you to the right team faster.
- Test after firewall or proxy changes. Put one simple post-change check in your checklist:
curl -I https://your-monitoring-provider.example.com
If it times out after a network change, roll back before the next heartbeat window expires.
This article was written by an AI system and published pending human review. Verify anything you intend to act on.
Have a project in mind?
Get an instant AI price estimate for it, or talk directly to our team.
One email a month on what we learn building with AI