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. Whole offices are watched too: an office losing its internet, or working from a backup line, is one alert for the office.
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.
Email and chat notifications follow the same principle: one incident, one notification. You are emailed when a new ticket opens or when an open incident escalates in severity. A machine that keeps re-crossing a threshold adds recurrence notes to its existing ticket instead of re-emailing everyone; closing the ticket re-arms notification. Rules that do not create tickets remind at most once every few hours per device.
Office internet outages
Helios spots a client's office losing its internet line, and an office working from a backup connection. One alert covers the whole office, never one per machine, and it clears itself when the office line is back.
It learns each office as a place, not a list of machines: a public address that two or more machines report from at the same time, on three or more working days in the last fortnight. Laptop-only offices are covered the same way as offices full of desktops.
To have it watched from the first minute, add the office's public internet address on the client, under Edit details. When two or more machines share an address, Helios also asks on the client page whether it is the office line, and one tap marks it. An address that no machine uses is never watched, so a typing mistake cannot raise an alarm.
- Office offline: the machines on the office line stop reporting within ten minutes of each other in working hours, and nothing comes back on that line for half an hour.
- On a backup connection: two or more of the office's machines now share one other address, such as a 4G router. Newer agents also report the office gateway, which makes this certain.
It stays quiet for the everyday things: one machine switched off, people going home at different times, a regular lunch, one person on a hotspot or a dongle, and a team each on their own phone on a travel day. Working hours are the client's business hours when you have set them, otherwise 8am to 6pm on weekdays in the client's time zone. The alert names the client, the machines, the time, and both connections with their provider, and it goes through the client's normal alert rule (Office Internet, on by default).
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.
The Health panel on every machine
The top of each machine's page shows what is wrong with it, once, with one fix. A drawing of the machine marks the part each problem is about: Wi-Fi, memory, the disk, start-up, or a fault shared with the office network.
Each problem is one line and one button. Update driver runs Helio's Wi-Fi driver update on the machine, and it never restarts it. Plan upgrade marks a memory upgrade as planned. Review apps opens the apps that start with Windows, where you can switch one off and back on.
Helios measures two problems itself. Short of memory means over 85% for an hour or more on several days. Slow to start means Windows took over 1 min 30 s on its recent starts. Tap a problem for the evidence: the days it ran short, the programs using the most, whether the memory can be upgraded, and what held up the start.
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.
Network devices: switches, firewalls, UPS, NAS and printers
Kit that cannot run an agent is watched over SNMP, read-only. Find it under Network Discovery on the client page and press Monitor. Give the SNMP community (v2c) or a v3 user with SHA or MD5 authentication and AES or DES privacy. The details are stored encrypted and are only ever sent to the agent that checks the device.
No extra box is needed. One Windows or Linux agent at the client checks each device every five minutes: the one that discovered it, when it is online. If that machine goes quiet, another agent at the client takes over.
What is read: whether it answers, every port's state, traffic and errors, a UPS's power source, charge and runtime, a NAS's volumes, and a printer's toner and errors. A switch shows its ports as a faceplate, so the erroring port is easy to spot.
The alerts are ordinary rules on the alert profile, so you can change or switch any of them off:
- Network Device Down: three missed checks in a row (15 minutes) from the agent that reached it before. Critical, ticketed and emailed. A device that agent has never reached shows as not reached, never as down.
- UPS On Battery: two checks in a row on battery. Critical, ticketed and emailed. It clears when mains power is back.
- UPS Battery Runtime Low: under 10 minutes of battery while on mains, which means a worn battery. Ticketed.
- NAS Volume Filling Up at 90% shows in the app; NAS Volume Almost Full at 97% is critical and ticketed.
- Network Port Errors (10 a minute for 15 minutes) and Network Port Saturated (90% busy for 15 minutes) show in the app and the morning email.
A wrong password shows as "refuses the credentials", never as down. Helio reads these devices in its daily review, and Ask Helio can answer "is any UPS on battery?". Agents need the network monitoring update (Windows 2.0.37, Linux 2.1.16 or later).
Your own event log monitors
Alert on any Windows event that matters to a client, not only the ones Helios watches for you. On an alert profile, add a rule with the metric Windows event log. Choose the log (System, Application, Security, or any channel such as Microsoft-Windows-PowerShell/Operational), and optionally a source, event IDs and levels. Then say how many in what window, for example "1 or more in 60 minutes".
Three ready-made ones are on the form: an account locked out (Security 4740), a SQL Server backup failed (18210, 3041) and a VSS writer error (8193, 8194).
Each Windows agent counts the matching events itself every five minutes, so it sees every log and every level, and a burst in one second is counted in full. The alert follows your rule like any other: severity, ticket, email, snooze and maintenance windows. It clears when a whole window passes with fewer matches. The newest matching messages are in the ticket and on the machine's Events tab. Needs Windows agent 2.0.37 or later.
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. A relay command is never re-run, so a rejected one stays rejected. The stored password is only handed over for the exact command a person approved. 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. The first time a relay reaches a target, it records the host key or certificate the target presents. From then on the relay refuses to run if that key changes, so a swapped machine never receives your credential.
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. Beside the grid, a Falling behind panel lists what is quietly slipping: backups overdue, tickets past their time, machines waiting on updates, machines that have gone quiet, disks filling up and restarts outstanding. Each line opens exactly the machines it counts. Device groups let you slice big estates (per site, per department) with their own alert profiles.
Alerts can heal themselves. Any alert rule can attach a healing script that runs automatically when the alert fires, documents itself in a ticket, and closes the ticket if verification passes. See Helio AI.
