Why a Device Shows Offline, and What to Check First

If a device in your device list shows Offline, there are two different situations that can put it there, and only one of them ever sends you an email about it. Here's what's actually happening, and what to check first.

Two situations, one badge — and only one sends an alert

Offline means one of two things: a device that reported in before and has now gone quiet for more than 24 hours, or a device that has never successfully reported in even once. Both show the identical Offline badge.

Only the first kind can trigger an offline alert email. The alert only ever looks at devices that have a recorded last-seen time and haven't updated it in the last 24 hours — a device that has never reported in doesn't have a last-seen time to check, so it's structurally excluded from that alert. It can sit at Offline indefinitely and you will never get an email about it. If a device never showed up after install, don't wait for an alert — go check it directly.

Both the badge and the alert currently use the same 24-hour figure, so in practice they agree on when a device counts as stale — but only one of them (the alert) also requires that the device reported in at least once before.

How often a healthy agent checks in

Once installed, the agent sends an initial heartbeat right away, then keeps sending one roughly every 30 seconds in the background while it waits for its next full scan (once an hour by default). So a working agent is checking in continuously, not just once per scan.

The failure mode that keeps a device from ever showing up

Only that very first heartbeat, sent at startup, can crash the agent — every heartbeat sent later is best-effort and won't stop the agent if it fails. But if that first one fails, the agent process exits, and the background service restarts it 30 seconds later, which hits the same failure and exits again. That repeats indefinitely. A device stuck in this loop never appears on your dashboard at all — it's not a device that "went offline," it's one that never successfully registered in the first place.

What to check, in order

1. Is the agent process actually running? Each platform's installer prints its own status command when it finishes installing:

   Platform	Status command
   Linux / Chrome OS	systemctl status vf-agent
   macOS	launchctl list | grep verifyfiltering
   Windows	Get-ScheduledTask 'VerifyFiltering Agent'

2. What do the logs say? On Linux, journalctl -u vf-agent -f. On macOS, tail -f /var/log/vf-agent.log. If you see the same heartbeat failure repeating every 30 seconds, that's the crash loop described above.
3. Is the subscription that issued this device's license key still Active? A license key only works while its subscription is Active. If that subscription is later canceled, a device that was already installed and running with that key will start getting rejected on every heartbeat from that point on — nothing on the device itself has to change for it to go quiet.
4. Was the device removed from your dashboard? A removed device's agent is deliberately refused if it tries to check back in, rather than silently reactivating. See re-registering a device after you remove it for what that looks like and how to bring it back.