Devices

The Devices page is the home view for every managed endpoint — servers, workstations, laptops, discovered network devices, and hand-entered manual assets across all the organizations you can access. This page covers the device list itself (columns and filters) and the device detail Info tab, including VPN presence and battery status.

The Device List

Columns

The list shows a compact set of columns by default — hostname, class, organization, site, OS, role, status, CPU, RAM, and last seen. Many more columns are available but hidden until you enable them through the column-visibility picker in the list toolbar, including:

OS version / OS build / architecture
Pending reboot and headless indicators
Power — battery charge and charging state (see Battery and Power Status)
VPN — active VPN/overlay clients (see VPN Presence)
CPU model, cores, total RAM, total disk
Agent version and watchdog version
WAN IP and LAN IP — the device’s public (egress) address as seen from the server, and its local network interface address. Both are sortable; see IP History for the timeline of address changes.
Tags, last logged-in user, uptime, enrollment date
Desktop access and reliability score
Serial, asset tag, location — inventory fields for manual assets (asset tag and location) and, where reported, serial number (manual assets and agent devices); see Manual Assets.

Your column selection and order are remembered per browser, so each technician can tailor the list to their workflow. Most columns are sortable by clicking the header.

Filters

Above the list you can:

Search by display name or hostname.
Build structured filters with the filter toolbar — status, OS, role, organization, site, group, hardware attributes, and more, combinable into saved filter conditions.
Switch the class facet between All, Agent (endpoints running the Breeze agent), Network (devices found by network discovery), and Manual (hand-entered assets — see Manual Assets).
Filter by VPN when the VPN column is enabled (see below).

Manual Assets

Not everything an MSP is responsible for runs an agent or answers a ping. A spare laptop in a drawer, a desk phone, a non-networked label printer, a loaner tablet out with a field tech — a manual asset records that equipment as plain inventory so it shows up in the same unified Devices list as everything else.

Discovered asset vs. manual asset

The rule is simple: does it have a network identity?

Has an IP address, hostname, or URL — it’s a discovered network asset (the Network class), found automatically by network discovery scanning and eligible for monitors, alerts, and topology. See Network Discovery if that’s what you’re looking for.
Does not — it’s a manual asset. You type it in by hand, and it carries no reachability at all: it was never “online” or “offline”, so its Status column shows Unknown rather than a misleading Offline.

Manual assets deliberately carry no IP, MAC address, monitoring, alerts, or remote access — those are all agent/network concepts a hand-entered row cannot answer.

Adding a manual asset

From the Devices page, open the Add menu next to the device list and choose Add asset manually… (the other item, Install agent…, is the existing agent-enrollment flow — the two share one menu since they’re both ways of adding something to your fleet). Fill in:

Site (required) — defaults to the organization’s only site when it has just one.
Name (required) — the label that appears everywhere else in the list.
Asset type — the same device-type list (printer, workstation, phone, etc.) discovered devices use.
Manufacturer, model, serial number, asset tag, location — free-text inventory fields. Location is a free-text field within the site (“Closet B, shelf 2”), not a structured address.
Assigned to — an organization contact (not a Breeze technician login) responsible for the asset.
Tags and notes.

Serial numbers are not required to be unique — the same manufacturer’s serial format can legitimately repeat across vendors. If you enter a serial that already exists in the organization, the form shows a non-blocking warning; it does not stop you from saving.

Editing, linking, and deleting

Select a manual asset’s row to reopen the same modal for editing. From there you can also link the record to an agent device or a discovered network asset once one shows up for that physical machine — for example, after IT installs the agent on a spare laptop that had been tracked manually. Linking is reversible (Unlink restores the manual record to the list) and never merges data destructively: the manual record’s inventory fields (serial, asset tag, location, assigned contact, notes) stay attached and surface alongside the linked device or asset. A linked manual asset drops out of the Manual segment — the fleet is never double-counted — until you unlink it.

Delete permanently removes a manual asset record (no agent to uninstall, so there’s no separate “remove” step). It’s available from the row actions and, for a manual-only selection, from the bulk actions menu.

Filtering and search

The Manual segment (and its Devices-list count) is independent of network discovery being enabled — a manual asset still shows up even in an environment with no network-discovered devices at all. Search matches a manual asset’s name, serial number, and asset tag. Structured filters apply only where they make sense for a manual asset: name, tags, asset type, organization, site, manufacturer, model, and serial number are supported; anything that depends on reachability or an agent (status, IP/MAC, last-seen, OS, agent version, metrics) is reported as not applicable rather than silently hiding the row without explanation.

Billing Coverage

The device Overview tab carries a Billing card answering “which contract line bills this device?”. It needs Contracts read access and a partner-scoped login, so techs without billing access do not see it at all. It shows one of four things:

Covered – one row per active contract line that bills the device, with the contract name, the line description, and why it matches: Org-wide, This site, Role: Server, or Group: VIP Laptops. Two contracts can both bill the same device; both rows show.
Not billed by any line – no active contract line reaches this device.
Not billed – the device is decommissioned or an ephemeral support-session machine, so it is excluded from billing entirely. Nothing is wrong.
Coverage unknown – a device group on an active contract could not be evaluated (a broken filter, for example). The card says so and offers a retry rather than reporting the device as unbilled.

The Role chip names the contract line’s configured role set, not the individual device’s role.

Only active contracts count, and the answer is computed live from the same rule the billing run uses, so the card and the contract’s own coverage warning can never disagree.

VPN Presence

Agents on Windows, macOS, and Linux detect active VPN and overlay-network clients on the device and report them to Breeze. Recognized providers:

WireGuard
Tailscale
NetBird
ZeroTier
OpenVPN
Cloudflare WARP
A generic VPN fallback for active tunnel interfaces that don’t match a known provider

Detection works purely from local signals on the device — tunnel interface names and addresses, corroborated by the provider’s running service or process. It is read-only telemetry: Breeze does not read keys, peer lists, or any VPN configuration, and cannot manage the VPN. For Tailscale, the device’s own DNS name is also reported.

Connected vs. disconnected

Each reported VPN carries a state:

Connected — the tunnel interface is up and carries an overlay address. The interface and addresses are reported.
Disconnected — the VPN client is installed and running on the device, but no tunnel is up. Only the provider and the detection source are reported; there is no interface or address to show.

A provider is only ever reported when the device gives a concrete signal for it — a tunnel interface, or a running service/process. Breeze never lists a VPN it merely guesses might be installed.

Naming tunnels on macOS

macOS tunnels are all named utunN, which carries no provider information. The agent resolves the owner per interface from the network extension that created it, so a Mac running several VPN clients at once still names each tunnel correctly.

Clients that create a plain utun from a background daemon rather than a network extension — NetBird and OpenVPN among them — expose no owner. Those tunnels are named only when exactly one known VPN client is running on the device; otherwise they show as the generic VPN provider rather than risk naming the wrong one. When a tunnel cannot be attributed this way, no VPN on that device is reported as disconnected either, since the unattributed tunnel may well belong to one of the running clients.

On the device list

Enable the VPN column via the column picker (it is hidden by default). It shows a badge per provider — connected VPNs first in the provider’s color, then any disconnected clients in a muted badge — is sortable, and adds a filter dropdown with:

All VPN — no VPN filtering
Any active VPN — only devices with at least one active VPN
One entry per provider seen in the current list (e.g. Tailscale), to show only devices running that provider

Hovering a VPN badge shows the full detail — interface, addresses, and DNS name, or disconnected for a client with no tunnel up. The filter matches connected VPNs only, so a device whose VPN client is running but disconnected does not count as having a VPN.

On the device Info tab

When a device has reported at least one VPN, its Info tab shows a VPN section with a card per VPN — connected tunnels first, then any disconnected clients:

Field	Description
State	Connected, or Disconnected when the client is running with no tunnel up.
Interface	The tunnel interface name on the device. Omitted when disconnected.
VPN IPv4 / VPN IPv6	The device’s overlay-network addresses.
VPN DNS Name	The device’s name on the overlay network (Tailscale).
Detection Source	How the VPN was identified (interface, adapter, service, or process).
Last Reported	When the agent last reported this VPN.

The section is hidden entirely when the device has reported no VPNs at all.

Battery and Power Status

For devices with a battery (laptops and other portables), the agent reports power status with every heartbeat:

Battery charge (percent)
Charging state (charging, discharging, full, or not charging)
Power source (plugged into AC or running on battery)
Estimated time remaining while on battery, or time to full while charging (where the platform reports it)

This surfaces in two places:

Device list — an optional Power column (enable it via the column picker) showing the charge percent with a charging/plugged-in icon, sortable by charge level. Devices without a battery show a dash.
Device Info tab — a Power section with the battery charge, charging state, power source, time estimates, and when the status was last reported. The section only appears for devices that actually have a battery.

The Device Info Tab

Opening a device and selecting Info shows the device’s identity and inventory at a glance:

Section	Contents
System	Hostname, display name (editable), serial number, manufacturer, model.
Device Role	The device’s assigned role and how it was determined.
Operating System	OS type, version, build, and architecture.
Hardware Summary	CPU model, cores/threads, RAM, disk, GPU, motherboard, BIOS version.
Power	Battery and power status (portable devices only — see above).
VPN	Active VPN/overlay clients (only when at least one is active — see above).
Agent	Agent and watchdog versions, status, last seen, enrollment date, system uptime, logged-in user.
Desktop Access	macOS remote-desktop readiness (macOS devices only).
Tags and Custom Fields	Organizational metadata, when present.

The Change History Tab

Opening a device and selecting Change History shows a newest-first timeline of what has physically and logically changed on that endpoint over time — a swapped disk, added memory, a new CPU, a BIOS update, or an operating-system upgrade. Use it to answer questions like “when did this machine’s RAM change?” or “did the OS get upgraded before that issue started?” without cross-referencing screenshots or asking the user.

Breeze detects these changes automatically: the agent takes periodic inventory snapshots and compares each one against the previous snapshot. Any difference is recorded as a change entry and surfaced here. A device that has just been upgraded to a newer agent records nothing on its first snapshot, so upgrading never produces a spurious burst of “added” entries.

What’s Recorded

Alongside the system-level changes covered in Change Tracking (software, services, startup items, network, scheduled tasks, and user accounts), the Change History tab records:

Category	Examples
Hardware	Memory capacity (for example, “4 GB → 8 GB”), CPU model or core count, total fixed-disk capacity, BIOS, and serial / motherboard changes.
OS Version	Operating-system version upgrades.

Reading the Timeline

Each entry shows:

Column	Contents
When	Timestamp of the detected change.
Type	The change category (Hardware, OS Version, Software, Service, and so on).
Action	Added, Removed, Modified, or Updated.
Subject	What changed.
Change	The before-and-after values — rendered as `old → new`, with additions shown as a new value and removals struck through.

Two filters narrow the list: a Type filter (including dedicated Hardware and OS Version options) and an Action filter (Added / Removed / Modified / Updated). The tab loads in pages of 100 entries with a Load more control, and is deep-linkable via the #change-history anchor.

Related pages: Device Groups for organizing devices into collections, Tags and Custom Fields for metadata, Change Tracking for software and configuration change auditing, and IP History for the timeline of a device’s network addresses.