The endpoint list and endpoint health

The endpoint list is the answer to one question: which of my machines are actually reporting right now. It is the most useful page in the endpoint half of the product and the one worth glancing at weekly, because a sensor that has quietly stopped reporting looks exactly like a machine with nothing wrong.

This article explains what a record contains, the exact status values and what each one means, how stale is worked out, and the ordinary explanations for a quiet machine — which you should exhaust before you start thinking about an attacker.

What an endpoint record holds

One record is created the first time a machine enrols, keyed to a stable fingerprint of that machine. Reinstalling the sensor updates the record rather than creating a second one.

• Hostname, platform and architecture, refreshed on every re-enrolment — so a renamed or re-imaged machine stops carrying old facts around.
• Sensor version, as reported when the machine enrolled. This is the column to filter on during a rollout; see Keeping the sensor up to date.
• Status, and a derived effective status. The distinction matters and has its own section below.
• Last seen, which is empty until the very first telemetry arrives.
• Enrolled at, and revoked at if the endpoint has been revoked.

The exact status values

Four values can appear. Three are stored on the record; the fourth is worked out at the moment you look.

The derivation is exactly this, and it is worth seeing because it explains a case people trip over:

if last_seen_at is empty        -> show the stored status
if last_seen_at is older than   -> show 'stale'
   15 minutes
otherwise                       -> show the stored status

So a machine that enrolled and never checked in shows enrolled, not stale — there is no last-seen time to compare against, and calling it stale would imply it once worked. And the stored status and the displayed one can legitimately disagree: a laptop switched off a month ago still has online stored on its record, and the list shows stale. The list is the one to believe.

The heartbeat, and why it is five seconds

There is no separate heartbeat call. Liveness is a side-effect of telemetry: whenever a batch of events is accepted, the machine's last-seen time is updated. The sensor flushes its queue every 5 seconds, or sooner if 64 events have piled up, so the effective heartbeat interval is five seconds.

A machine with genuinely nothing to report still touches the record. On Linux and macOS, where the richer collector is unavailable, the sensor emits a heartbeat event every 30 seconds, and that counts as telemetry like anything else.

That is the arithmetic behind the fifteen-minute threshold: it is comfortably longer than any normal gap — a hundred and eighty times the usual five seconds — and short enough that an administrator watching a rollout notices a machine that never came back. It is not tunable.

Why the status is worked out rather than stored

This part is here because it explains a defect we shipped and then fixed, and because the fix has a consequence you can see.

The fix computes staleness when the list is read, rather than writing rows during a read. Mutating records on a GET would turn a list page into a writer, make it contend with incoming telemetry for the same rows, and still be wrong — because a record would only be corrected when somebody happened to open the page it appears on. The truth about your fleet would depend on who looked at which screen.

The ordinary reasons a machine goes stale

In roughly descending order of frequency. Work down this list before you reach for a more exciting explanation — a sensor being deliberately killed by an intruder is real but rare, and it looks identical to a closed laptop from here.

1. The machine is off, asleep, or away from the network

By far the most common. A laptop shut for the weekend, a machine on someone's leave, a site with the VPN down, a desktop unplugged for a desk move. What to do: check whether the machine is expected to be on. If it comes back and starts reporting on its own within a few minutes of being woken, there was never a problem. Machines that are stale for weeks are worth retiring from the list so the real signal is not buried.

2. The service is not running

Stopped by hand, killed by something else on the machine, or left down after a reboot or a failed upgrade. What to do: sc query QorionixSensor on Windows, sudo systemctl status qorionix-sensor on Linux. The Linux unit restarts itself up to ten times in five minutes and the Windows service restarts after 60 seconds, so a service that is genuinely down has usually failed repeatedly — sudo journalctl -u qorionix-sensor -n 50, or the Windows event log, will say why.

3. Outbound HTTPS is broken

A new firewall rule, a proxy that requires authentication, a TLS-inspecting appliance the sensor does not trust, or DNS failing for the API hostname. This is the usual cause when several machines on one site go stale together. What to do: look for sensor: cannot reach <endpoint> (<err>) — <n> events dropped in the log, and test outbound HTTPS to your API URL from the machine itself. A wrong system clock lands here too: an out-of-date clock breaks certificate validation and reports as an unreachable server rather than as a clock problem.

4. The credential is being refused

The endpoint was revoked, or the config file was replaced with one belonging to a different machine. What to do: the log is explicit. A 401 gives you sensor: the server rejected this endpoint's credential (HTTP 401). Re-run the installer with a fresh enrolment token, or check the endpoint has not been revoked in the console. A 403 gives you sensor: the server refused this endpoint's identity (HTTP 403). This usually means the local config names a sensor that belongs to a different machine. Re-enrol with a fresh token; see Enrolment tokens.

The messages the sensor writes when delivery fails are throttled to one line per distinct message every five minutes, with a (<n> similar messages suppressed) suffix, so an overnight outage leaves a readable log rather than a gigabyte of the same sentence. When it recovers you get one line saying so:

sensor: cannot reach <endpoint> (<err>) — <n> events dropped
sensor: telemetry rejected with HTTP <code> — <n> events dropped
sensor: telemetry delivery recovered

Note the phrase events dropped. Telemetry is not queued to disk indefinitely and replayed later; events produced while the platform is unreachable are lost. A machine that was offline for a day has a day-shaped hole in its history, and that is worth knowing before you go looking for evidence from a period you know was disconnected.

Revoking an endpoint

Revoking is for a machine you no longer control — sold, lost, decommissioned, or rebuilt for someone outside the organisation. A revoked endpoint's credential is refused at authentication with sensor auth: sensor revoked, so even a restored disk image cannot report with it. Note that revoking the enrolment token a machine was installed with does nothing to that machine; the two are separate, and Enrolment tokens explains why.

Uninstalling the sensor does not revoke anything. The endpoint stays in the list and reads as stale, indefinitely. If you want it gone from the picture, revoke it explicitly.

One piece of vocabulary to ignore

If you go looking through the API you will find an older, separate notion of an endpoint, created by an operator call rather than by a sensor enrolling, with its own set of status values including degraded. The console's Endpoints list is not that one, degraded is never actually set by anything, and nothing in the sensor talks to it. It exists behind an older response-action path. We mention it only so that finding it does not send you looking for a health signal that is not there.

The View details modal

Selecting View details on a row opens a per-sensor modal with more than the list columns show: whether this specific machine actually applied the policy the server built for it, its package inventory and any CISA-KEV-flagged findings, and quick actions including Isolate, running a response script, and Preview effective policy. See Endpoint detail and applied policy for what each of those shows and what the quick actions genuinely do.

What to do next

1. Enrolment tokens — for a machine that enrolled but has never checked in.
2. Installing the sensor on Windows and on Linux — for reinstalling one that will not come back.
3. Keeping the sensor up to date — this list is also how you verify a fleet upgrade landed.
4. How to get help — send the hostname, the displayed status and the last fifty lines of the sensor log; that is usually enough to answer it in one reply.