Skip to content

Host detail page

After creating a host (or clicking one from the hosts overview) you land on the host detail page. It's organized into tabs; which tabs show up depends on the host.

Tabs

Tab When visible
Checks always (default)
Telemetry agent hosts only
Docker Linux agent hosts on which Docker was detected — after clicking "Docker detected"
Device only when a check feeds a device visualisation (switch port map, UPS panel, NAS disk bay, firewall)
Logs agent hosts only
History always — views Check history, Changes in Vesana, Downtimes & ACKs and Notifications

Following a link to a tab that isn't available for this host silently lands you on Checks — no error message.

Checks

Header card + health strip + StatusPillsBar + optionally a telemetry or device snapshot, then the checks table below (the heart of the page). If a monitoring source is offline, a hint appears: "{{source}} offline since … — {{count}} checks aren't receiving data."

Telemetry

A compact list of every resource the agent reports — System (CPU with iowait/steal or load, RAM), Volumes, Network (throughput per interface), Disks (utilization, SMART health, wear, read/write rates) and Sensors — each row with its value, a mini curve of the last 30 minutes and the check that monitors it. Virtual interfaces (containers, VMs) are collapsed.

Clicking a row opens its check — the same check detail as in the check list, with history, configuration, ACK and downtime, right next to the telemetry. ↑/↓ moves to the next row. A volume opens the disk check with exactly that volume in the history. If a resource has no check yet, monitor creates one, preset to exactly that resource (see Network throughput, disk load, temperature). The same goes for the top processes: a monitored process opens its check.

Below: eventlog/journal, logged-in users, pending reboot and the deep-analysis sections (hardware/inventory/network/security/lifecycle). The CPU/RAM/disk values in the host header open their check as well.

Docker

At the top, tiles (running, problems, restarts, updates, disk) and a line with the host's Docker version. Below, every container with status, image, version, CPU (with the last 24 h), RAM, network, restarts, ports and uptime; Compose projects are collapsible groups, groups and containers with problems first. Clicking a container opens its detail: why it is red (exit code with its meaning, killed by the kernel for lack of memory, last healthcheck output), image, version, restarts, created, image age and size, CPU/RAM/network with a 24 h curve, ports, networks and volumes. The version comes from the image label org.opencontainers.image.version, otherwise from the tag (latest is not a version). “Update” means the registry serves a newer image for the same tag; the agent asks at most every 6 hours, only for public images, or the newer image is already on the host while the container still runs the old one; it never changes a status (can be turned off with “Check for newer images”). The agent measures disk usage every 30 minutes. Vesana only shows — starting or stopping containers is not part of monitoring. The new details need a current agent. The basis is the Containers (Docker) check — it reports four problem types: unhealthy (healthcheck), stopped despite a restart policy, crash loop, and stopped/missing required containers. Each problem type has its own severity (off / WARNING / CRITICAL, default CRITICAL) in the check configuration; once a threshold is set, the number of problem containers decides instead (for example “warning from 1, critical from 3”); the severities then only define what counts. Exceptions: a list of excluded containers (wildcards allowed), excluded Compose projects, a per-container-and-problem-type exception (container:reason), and the Docker label vesana.ignore=true directly on the container. Further settings: treat cleanly exited containers (exit code 0) as not a problem (for job/init containers), "all containers must run" (every stopped container counts, regardless of its restart policy), and crash-loop sensitivity (number of restarts within a time window). The "Per container" graph shows the CPU history per container.

Device

The device view built from blocks — switch ports, NAS disks, UPS, firewall, internet line, plus values and tables from the device data, graphs and notes. It is fed by any check that delivers a device snapshot (SNMP or agent script) and always shows the latest run. Customisable for this device or the whole profile.

Logs

Collected agent logs.

History

  • Check history — every stored value and status change of this device: the same console as the Global Log, restricted to the host. Your own tabs and filters apply to every device. Whoever may see the device may also see its past — the Viewer role needs no diagnostic log permission for it.
  • Changes in Vesana — who created, changed or deleted the device and its checks in Vesana (thresholds, intervals, created/deleted) — not what happened on the device itself.
  • Downtimes & ACKs — all maintenance windows and acknowledgements of this device, with filters and paging; create, edit and lift them right here. The check detail only shows the latest ACK or downtime, a click leads here.
  • Notifications — what Vesana sent about this device: channel, state, error text, next attempt; searchable by state, trigger, channel, time range and full text. Messages without a check (e.g. "device unreachable") are listed too. Only visible with the permission to view notifications.

A back link says "Back to hosts". The card shows:

  • Profile icon, colored by the worst current status
  • Heading = display name (or hostname, if none set)
  • Line 2: hostname, IP as a mono chip, profile/type, tag chips
  • Dependency chip — "depends on: {{name}}" or "{{count}} dependencies", with actions "Manage dependencies …" and "Show on map"
  • Maintenance chip (violet) — "Maintenance until {{until}}" or "Downtime"
  • Description, a note strip
  • Source chips — which monitoring sources are active (agent/collector/active checker), with an uptime popover per source. The agent chip shows whether Agent Lock is active and how many approvals are waiting. If an agent has never reported, the chip shows "Agent not yet installed" (only if the host has agent checks, otherwise "Agent not connected"); "Remove agent" detaches a started agent setup from the host. The agent commands on the device itself are listed under Commands on the host.

Top right: "Show on map" and "Manage host" (opens the manage panel with the tabs General, Connection, Checks and Alerting — General covers name, description, site, note, tags and device visualization; Connection covers target, profiles, monitoring sources and credentials). When space is tight both shrink to their icons instead of dropping into a row of their own.

Compact mode

The toggle on the right of the header collapses it into one line: name, health, status pills (still usable as filters), telemetry and all actions as small icons — so the checks move up. Description, tags and explanatory texts stay in the expanded header, one click away.

The choice is stored per user on the server and applies to all devices and all browsers. Depending on the available width the collapsed header picks one of three arrangements (single line · title on top with state below · stacked); on a phone the icon buttons sit in their own row below the name.

There's no separate site chip in the header — the site is set via "Manage host" (see Sites).

Health score

The Health badge shows a colored dot, the word "Health" and the score as "{score} /100" (green from 90, amber from 70, otherwise red).

Formula:

Score = (OK checks + WARNING checks × 0.5) / max(1, open checks) × 100

Only open (non-suppressed) active checks are counted — downtime, accepted and info-mode checks leave the denominator, "In progress" still counts as an open problem. As long as a host has any problem, the score is capped at 99 — a single WARNING never rounds up to 100.

Tooltip: "Score over open checks: OK counts fully, WARNING half. Downtime, ACK (marked as no error) & info mode are excluded; ACK (marked as error) still counts as an open problem."

Subtext: "{{ok}}/{{active}} checks OK", plus for problems "{{count}} need attention", and whenever checks were excluded, always "excluding downtime, accepted & info ({{count}})".

StatusPillsBar

Two groups, separated by a divider:

  • Status group (every active check counts exactly once): Critical, Warning, No Data, Pending, Unknown, OK, Info (teal — checks in info mode, whatever their real status)
  • Treatment group: ACK (marked as error) ("in progress"), ACK (marked as no error) (Accepted), Downtime (violet)

Freshly created checks ("awaiting data") do not lower the health score — they form their own blue pending share; info-mode checks never count as a problem. During flapping the status tooltip of a row says whether a notification really goes out (with channels) or why not — downtime, ACK, info mode, no matching rule, status filter or no active channel.

Each pill is a filter toggle for the checks table below. Pills with a count of 0 aren't shown.

Checks table

Columns (toggle them via the columns menu; resizable except checkbox/status/check/action):

Column Note
Checkbox for bulk actions
Status color dot
Check name; type and execution are in the tooltip on the name
Message flexible absorber — takes up remaining width
Value incl. sparkline
Last change relative (e.g. "3 min ago")
Last checked absolute, hidden by default
Type check type, hidden by default
Execution active checker/collector/agent, hidden by default
Action per row

Checks with a reachability hint show a radar icon; checks in info mode show a teal "Info" badge (info-mode checks never alert, but keep running visibly — see the alerting concepts).

PENDING

A freshly created check without a first result shows status PENDING — rendered in blue. Conceptually: "waiting for data", not an error state.

The status holds until the agent or collector has actually measured (from v1.9.442). Before that, the server tried to run a freshly created agent or collector check itself and stored that non-result as UNKNOWN — the blue status was gone within seconds. The check is still handed to its execution point immediately; the first result arrives with its next fetch, not only after the interval.

Order and pinning

Without a setting of your own, checks appear in the order of their profiles (see Editing profiles); checks without a profile follow alphabetically.

  • Reorder: drag the grip on the left of the row, or use the keyboard (Space, then arrow keys). The order is saved and applies to all users. Dragging only works while no column sort, filter or search is active; inactive checks always stay at the bottom.
  • Pin to top (row menu, right-click or the pin at the name): pinned checks stay on top, followed by a divider line. Dragging a row above the line pins it, dragging it below unpins it.
  • If a device has its own order or pins, the toolbar shows "Custom order" — a click resets it to the profile order (with undo).

Inactive checks

Disabled checks are hidden by default. A pill "{{count}} disabled" shows them.

Bulk actions on checks

Via the checkbox column, several checks can be handled at once:

  • ACK (n)
  • Downtime (n)
  • Edit (n)
  • "Check now" — only for checks with check_mode='active'
  • Disable / Enable
  • Delete — moves to trash ("…will be moved to the trash and can be restored from there.")

Select-all only picks what you see

If the table is filtered, "select all" only picks the visible rows — a bulk action never touches a check hidden by the filter.

Check detail panel

Clicking a row opens the detail panel on the right (URL parameter, so it's shareable/linkable). Close with Esc or X, navigate with ↑/↓. The underlying data list is unfiltered — the panel stays open even if the check recovers to OK in the meantime.

"Edit" in the panel opens the configuration tab. The panel and "Manage host" are mutually exclusive — both dock on the same right side.

Besides message and graph the panel shows the rich result details a check delivers (tables, lists, figures — e.g. top processes for the load check, the VM list for Hyper-V, backup jobs), for info checks the real status on click, the threshold reasoning ("71 % ≥ 50 % ⇒ WARNING · warning from 50 % — from the profile") right next to the measured value, the delivery journal ("Recent deliveries") and, for multi-value checks, a graph with a clickable legend (drives, load 1/5/15, series from scripts).

Full screen: clicking "Full screen" opens the check in the same tab (Ctrl/Cmd or middle click in a new one) — three tabs Analysis (graph with time range 1 h to 1 year plus custom range), Status (full message and details) and Configuration (all settings in full width, next to what the check type probes and how its status is derived). Status, value and message stay above the tabs; the tab is part of the URL and can be shared.

Device scan

For every host with a network target (except pure agent hosts), the checks toolbar has a secondary button "Device scan" (tooltip: "Tries known vendor checks against the device and suggests available ones (optionally: deep SNMP walk)").

The button opens a modal with a collapsible section "Search deeper (walk)" — that mounts the actual SNMP sensor picker (see SNMP sensor picker) directly inside the modal. If an SNMP community is missing, the modal asks for one first.

The scan uses the host's SNMP version (including SNMPv3). Without a collector, the server probes the targets in parallel and ends a scan on hard-to-reach devices after 3 minutes with a partial result ("time budget exceeded"). On devices with a collector, the created checks run via the collector. Suggestions the host already measures are marked "Present: " and are not pre-selected.

The former separate "Pick SNMP sensors" button no longer exists — the walk is now part of the device scan.

Profiles of the host

A host can carry several profiles, e.g. a Windows base profile plus an add-on profile for SQL Server. One of them is primary — it determines icon, device visualization and suggestions.

Under "Manage host" → Connection you pick the profiles via a multi-select with search; with more than one profile the dropdown "Primary profile (icon, visualization, suggestions)" appears. "Create the default checks of newly selected profiles" adds the auto-add checks of newly added profiles right away. Existing checks are kept when you change profiles.

Tags

Tags are free keywords on the device. Edit via "Manage host" → General, field "Tags". An input field (placeholder "Type a tag + Enter…") accepts new tags; below it, suggestion chips ("Suggestions:") from the tenant-wide tag vocabulary appear (up to 12, click to apply) — this prevents typo variants of the same tag.

On the hosts overview, a multiselect dropdown "{tag} ({count})" filters case-insensitively by tag; the option only appears if tags exist in the tenant.

Sites

A host can be assigned a site — both when creating it ("More details" in the form) and later (Manage host → General, below name/description).

The field is labeled "Site" in the UI: a searchable, clearable dropdown over all sites of the tenant (empty option "No site") plus a "+" to create a new site inline (name + optional place search for lat/lon).

Separately there's a free geo override: "Custom location override (optional)" — for when a device is geographically different from its assigned site.

On the backend, the site is the sole source of geo truth: when a coordinate is needed (e.g. for physical maps), a host's own coordinate wins over the site's coordinate, otherwise the site's coordinate is used.

Delete & trash

Deleting a host in the UI is always a soft delete: the host (cascading to its checks) moves to the trash. All confirmation dialogs phrase it that way too ("…to the trash") rather than "delete permanently".

Restore via the Trash page (scope-dependent: own/tenant/system trash). It has tabs per object type — including "Host" — plus "All", services, dashboards, maps, alert rules, notifications, collectors, scripts. "Restore" per row brings the object back.

A background job permanently purges trash entries older than 30 days.

Next