Host stuck NO_DATA / grey¶

A check permanently shows NO_DATA (orange), or an entire host looks "grey" — none of its checks receive new values. This guide walks you from the symptom to the cause, split by monitoring mode.

First look: PENDING or truly NO_DATA?¶

A freshly created check first shows PENDING ("waiting for data", blue marker) — that's the normal state between creation and the first result, not a fault. Only a check that already had at least one result and then stays silent for a longer time turns into NO_DATA. Details on the difference: Status and state model.

So if you just created the check: wait out the regular interval first before reading on.

Step 1 — which monitoring mode?¶

On the host detail page, the header shows the SourceChips — one chip per monitoring source (Agent / Collector / Active-Checker) with online/offline status and an uptime popover. That's the fastest answer to "who should even be delivering data here". A host can have several modes at once (e.g. an Agent and an SNMP check via a Collector).

flowchart TD
    A["Check shows NO_DATA"] --> B{"Which mode per the SourceChip?"}
    B -->|Agent| C["Check agent.log on the target machine"]
    B -->|Collector / passive| D["Is the collector online?"]
    B -->|Active-Checker| E["Is the Active Collector online?"]
    C --> C1["401/403 → token · 404 → server URL · 0 checks → nothing assigned"]
    D --> D1["Offline → check the collector side"]
    E --> E1["Offline → Python fallback runs, but slower"]

Agent host¶

If the SourceChip for "Agent" shows offline, or it's online but the check stays silent anyway — agent.log on the target machine is the first place to look, not the Vesana UI.

Finding and reading agent.log¶

Platform	Path
Linux	next to the config, i.e. `/etc/vesana-agent/agent.log`
Windows	`C:\ProgramData\Vesana\Agent\agent.log`

The log is plain text, local time, level as a word — no structured format to parse:

2026-07-04 10:15:03  INFO   Results sent  checks=5

The agent writes typical causes as a clear error message instead of swallowing them silently:

Log content	Meaning	Fix
`401 Unauthorized`	Token wrong, revoked, or a new one was generated	Enter the new token on the machine, restart the service
`403 Forbidden`	Token belongs to a different host	Regenerate the token for this host
`404`	Wrong server URL (path/domain doesn't match)	Check the server URL in the config
"0 checks"	Host has no services assigned yet	Add checks on the host page
`dial tcp: lookup …: no such host`	DNS resolution fails	Check the DNS resolver on the target machine
`x509: certificate signed by unknown authority`	TLS certificate not trusted	Real certificate, or import the cert into the system trust store
`connection refused`	Server unreachable	Check server reachability/port

Non-OK results are additionally logged with a plain-text message — OK results deliberately stay at debug level so the log doesn't flood. If agent.log shows no entries at all for the affected check, it's likely not configured on the agent side (see "0 checks" or config poll below).

Hostname correlation¶

The server matches incoming results using the combination (tenant, hostname) — not an internal ID the agent would need to know. If the host was renamed in Vesana (the internal hostname slug, not just the display name) after the agent was already running, the agent may keep reporting the old hostname — the correlation then no longer matches cleanly. Check: does agent.log run without errors, but the host still stays NO_DATA? Compare the hostname in the config against the host's current internal name.

Is the agent even online?¶

The agent sends a heartbeat roughly every 20 seconds — that's the basis for the online status shown in the SourceChip. The actual check configuration (new/changed checks) is fetched separately, typically every ~5 minutes. Threshold changes take effect immediately regardless (the server applies them server-side to every incoming result); other config changes (event log filters, service exclusions, new checks) need the next poll.

Right after a change, instead of waiting for the next cycle:

vesana-agent test

Runs all checks configured by the server once, shows each result live, and sends the batch — confirms in one step whether the configuration arrived and whether the check produces sensible values at all.

The Windows agent stops reporting after an update¶

Up to v1.9.443 the Windows service stayed stopped after every self-update: the agent replaced its binary, shut down cleanly — and never came back. A Windows service cannot restart itself through a child process; that child is killed together with the service.

Immediate remedy on the machine: Start-Service VesanaAgent (or sc start VesanaAgent). The binary is fine, only the restart was missing.
Fixed in v1.9.444, and since v1.9.445 with two independent ways back: a one-off task in the Windows task scheduler (it belongs to the scheduler and survives the agent's death) and — should that fail — the Windows service manager's recovery actions, which are re-applied on every service start and therefore also cover old installations.
The transition itself still runs the old binary: an agent below v1.9.444 stops one last time when updating to v1.9.444 and needs a single Start-Service. After that it returns on its own.
The restart is logged in restart-helper.log next to agent.log.

Linux agents count as offline after the public IP changes¶

When the site's public address changes (nightly forced reconnect, CGNAT, mobile uplink), Linux agents and collectors counted as offline for up to 15 minutes up to v1.9.447, although they were running — Windows was not affected. The cause was a dead connection held open for minutes. From v1.9.448 it is replaced on the first timeout; the outage is down to seconds.

How to recognise it: the heartbeat gap starts reproducibly at the same time of day (the forced reconnect) and hits all Linux agents of the same site at once.

After an outage, checks with long intervals still show No Data¶

If the server or the network was gone for a while, checks with long intervals (hours, days) stayed without data until their next tick, although the agent was sending again. From v1.9.446 all checks of a host run immediately after it returns; "Collect now" on the host also measures the whole host — for agent, collector and active-checker hosts.

Token regenerated?¶

Was a new agent token generated on the host page (e.g. because the old one was lost), but the target machine still runs with the old token in its config — then the server consistently reports 401. The old token becomes invalid the moment the new one is generated, not at some later point. Fix: enter the new token into the config, restart the service.

Full installation and token details: Agent (Linux/Windows).

Collector host (passive)¶

If the "Collector" SourceChip shows offline, that's usually the entire reason — every check that runs through this collector stays silent, not just one.

Is the collector currently online? A collector only counts as online if it recently (in practice: within a few minutes) sent a heartbeat. On the collector VM: journalctl -u vesana-collector --since '5 minutes ago'.
Is the host actually assigned to this collector? A host without a collector_id can't get passive checks.
Did you wait out the config refresh? The collector fetches its check list roughly every 60 seconds — shorter than the agent, but not instant.
SNMP-specific: if only one SNMP check fails while the collector itself is online, test the community directly from the collector VM (snmpwalk -v 2c -c <community> <target-ip> .1.3.6.1.2.1.1.1.0) — if that already fails, it's network/community, not the collector.

Details: Collector.

SSH checks sit on Unknown: "credentials rejected"¶

If a device rejects the SSH credentials, Vesana remembers that per target (address, port, user) and attempts no further login for 15 → 30 → 60 minutes. All SSH checks of that target report UNKNOWN with plain text (user, target, end of the pause) — without opening a single connection.

That is deliberate: previously up to six failed attempts ran per check and interval. To the target device that looks like an attack — ESXi locks the account after five failures, other devices put the address on a block list.

The pause ends immediately on:

changed credentials on the host or in the credential set,
"Check now" or "Collect now" on the host,
the first successful login.

Passive checks have no "Check now" — there the status panel offers "Retry login now"; the collector then runs all checks of the host at its next configuration fetch.

For contrast: if the device is not reachable over SSH at all (connection refused, timeout), the check is CRITICAL, not UNKNOWN — then it is not a credentials problem.

Active-Checker host¶

Active checks normally run through the Active Collector — a service running directly on the Vesana machine. If the Active Collector is offline (no heartbeat within the last ~2 minutes), the worker automatically falls back to a slower Python fallback — checks keep running, but with higher latency and reduced functionality (e.g. no SNMP walks). In this case a host tends to run delayed rather than turn fully NO_DATA.

If everything still stays silent, first check whether the Active Collector is even set up (Admin → System → Active Collector). Details: Active Collector.

Key regeneration on the Active Collector

Regenerating the Active Collector's API key while it's running disconnects it immediately — the old key becomes invalid the moment the new one is created. Only do this combined with an immediate redeploy of the new key on the machine.

Cross-mode causes (all modes)¶

Cause	Symptom	Fix
The host's reachability hint is alerting	Host card shows "unreachable", child checks suppressed	Check Reachability hint
A parent (dependency) is down	Host header shows "depends on: …" in a warning color	Dependencies & inhibition
Check is in info mode	Teal "Info" badge — status runs, but never alerts	Not a fault, intended behavior
Worker isn't processing results	Diagnostics log category "result processing" shows an error	Check the Diagnostics log

If none of this helps¶

Build a support bundle — it includes ingest statistics, the state of the processing pipeline, and the latest diagnostic events in one shot.