Operate

Monitoring and alerts

Agents report metrics continuously; alert rules turn those metrics into alerts; a deliberate noise policy decides which alerts deserve a ticket. The goal is a queue you actually read.

Alert profiles and rules

Every client runs an alert profile: a set of rules like "disk above 90 percent for 15 minutes is a warning" or "server offline is critical". Built-in profiles cover typical estates; you can clone and tune them, add per-client or even per-device rules, and target rules at servers only or workstations only.

Monitored signals include CPU, memory and disk usage, predicted days until a disk fills, offline state, pending reboots, missing antivirus, a stopped print spooler, a disabled firewall and stale backups.

The noise policy

Alerts and tickets are deliberately not the same thing. Warnings raise alerts but do not create tickets. Only criticals, security findings and backup failures auto-ticket. A human can promote any warning to a ticket with one click. This default exists because a board full of "CPU was briefly high" tickets trains people to ignore the board; you can change it per rule if your process differs.

Health scores

Every device carries a health score computed from its live state: resource pressure, patch debt, protection gaps, backup freshness and pending reboots. Scores roll up to the client and the whole estate, so "which client needs attention this morning" is one glance at the dashboard, which also carries an AI digest of what to look at first.

Predictive disk alerts

Alongside the classic percentage threshold, Helios fits a trend to each disk's usage and estimates days remaining until full. That converts "disk at 91 percent" panic into "this disk has about nine days left", which is a schedulable job instead of an interruption.

Website and service checks

Each client can have web checks: URLs polled from the platform every five minutes, recording status, response time and days until the SSL certificate expires. Two consecutive failures mark the check down and raise a high-priority ticket; recovery closes it automatically, so a flapping site does not open a new ticket every bounce. A certificate within seven days of expiry raises its own ticket. Set these up on the client page under the Web checks tab.

Network discovery

Agents passively watch each network they sit on and report what else is there. Helios identifies discovered hardware by vendor and type, so the list reads "Hewlett Packard printer, Synology NAS, Ubiquiti network device" rather than a wall of MAC addresses, and flags randomised MACs for what they are. Technicians can rename or ignore entries. After a 24-hour baseline, new devices on a client network are summarised in one chat notification rather than a ticket per device, per the noise policy above.

Site relays: acting on kit that has no agent

Any managed device can be nominated as its site's relay from the Relay tab on its device page. A relay runs commands on other devices on its network, so switches, firewalls, NAS boxes, printers and servers you have not enrolled yet can be acted on rather than only discovered. Choose the target, a credential from the vault, and a protocol: WinRM runs PowerShell against Windows machines, SSH runs a shell command against network kit and Linux. The port follows the protocol (5985 and 22) and you can override it, for example 5986 for WinRM over HTTPS.

Three rules make this safe, and none of them can be turned off:

• A relay can only reach what it discovered. Targets come from that relay's own discovery results, so a relay cannot be pointed at an arbitrary address on the network.
• Every command waits for a human. Commands are created awaiting approval and the agent is only ever served approved ones, so an unapproved command cannot reach a machine at all. This is deliberately different from auto-healing, which runs without a human in the loop.
• The password is never in the command. The queued command holds a reference to a vault entry, not a secret. The relay exchanges it for the credential at the moment it runs, and that access is recorded in the vault audit trail.

Relays need a recent agent: 0.12.0 or later on Windows, and on Linux 0.2.0 for SSH or 0.3.0 for WinRM. Older agents are told so with a clear message rather than leaving a command queued. macOS cannot act as a relay. Note that a relay currently trusts the host key or certificate a target presents on first contact; the fingerprint is recorded with each command so a change is visible, and pinning is on the roadmap.

The WinRM target has to be listening. This is the usual reason a first attempt fails, and it is a setting on the target rather than anything in Helios. Windows Server runs the WinRM service by default but still needs a listener and a firewall rule; desktop editions of Windows 10 and 11 have it switched off entirely. On the target, an elevated winrm quickconfig starts the service, creates the listener and adds the firewall exception, or you can push the same thing across an estate by Group Policy. Until that is done the relay will report a connection failure, with the underlying error, rather than appearing to hang.

Acting on a compromised device

From a device's Security tab you can isolate it from the network in one click: the agent applies a default-deny firewall that leaves only the Helios connection, DNS and DHCP alive, and it verifies it can still reach the platform before keeping the rules, rolling back automatically if not, so isolation cannot strand a machine. You can also trigger an on-demand Microsoft Defender quick or full scan. Both actions require an agent on version 0.11.0 or later; older agents return a clear error instead of failing silently.

The war room

The War Room is a full-screen grid of every device in the estate, coloured and sorted by severity, built for a wall display or an incident. Device groups let you slice big estates (per site, per department) with their own alert profiles.