## 0.3.3 (2026-10-05)

### Changed
- Settings are grouped into Your account, People & sign-in, Server, Backups & high availability, Monitoring, and Help & about. Banners about the licence, updates and the disk open the Server group.
- The programs in a release carry no symbol table or debug information, which makes them harder to take apart.

### New
- API guide: the API keys card's API guide and reference opens on Common tasks, with worked examples (curl and PowerShell) for devices, sensors and their history, alerts, pausing with a reason, maintenance, the audit trail and Power BI. Every route lists the rest. The same guide is in docs/api.md, and the training course's Administration chapter covers keys and the API.
- The audit trail opens every event ever recorded, 50 at a time, instead of only the last 100. Search covers actions, people, objects and reasons, alongside filters for action, person and date range, and Download CSV saves everything that matches. Actions TarleyNode takes by itself are named (TarleyNode scheduler, TarleyNode (automatic)) instead of "Unknown actor".
- The Overview shows the number of sensors beside Infrastructure health.
- Pausing a sensor asks why. The reason, who paused it and when show on the sensor (on the phone app too), and the audit trail keeps the reason with the pause. Pausing many sensors in a bulk edit asks once for all of them; sensors paused to fit TarleyNode Free say so.
- A restart between two readings is caught: when a device's uptime goes backwards, TarleyNode records that it restarted and when, as an incident that is already over. A reboot shorter than the check interval used to go unseen.
- Scans look for DNS (port 53), and devices that answer it, such as firewalls and domain controllers, get a DNS check.
- Devices with automatic discovery added before the certificate and DNS checks existed get them from their last scan, at start-up and after every scan. A check someone removed is not added back.
- XCP-ng and Citrix Hypervisor monitoring (beta) through XAPI on the pool master: pool health (hosts live), hosts (memory), virtual machines (running), and storage repository use, with the pool's hosts, VMs and storage listed under Sensors to tick.
- Nutanix monitoring (beta) through the Prism Element API: unresolved critical and warning alerts, hosts (CPU, memory, state), virtual machines (powered on), and storage container use, with everything listed under Sensors to tick.
- Beta integrations say so in the console and ask for a support pack when a reading looks wrong.
- Proxmox VE monitoring (beta) through its API with a read-only token: nodes, virtual machines and containers (CPU, memory, disk, running or not), storage use, cluster quorum and nodes online, and backup job results. Once one Proxmox check is added, every node, guest and storage is listed under Sensors to tick; nodes and storage are monitored automatically.
- Veeam Backup & Replication monitoring (beta, version 12 or later) through its REST API with a read-only login: each job's last result, failed and warning jobs, hours since the last run, and repository free space with a warning level.
- A sensor page laid out like PRTG's: last scan, last up and down, uptime, downtime and coverage at the top; Live, 2 days, 30 days and 365 days; every channel on one graph per unit, with a legend to show and hide channels, the highest and lowest readings marked, downtime shaded and a bar to zoom; and the readings below as a table with averages and, for traffic, volume and speed, totals and a CSV download. A port also shows its total traffic.
- Windows performance counter checks: read any Performance Monitor counter over WinRM, or pick from common ones (CPU, processor queue, memory, disk queue and latency, TCP, IIS, ASP.NET, SQL Server, Exchange). The check names any counter the computer does not have.
- Web transaction checks: open several pages in order with cookies kept, such as a sign-in page, the sign-in and a page behind it. Form fields can take {username} and {password} from a stored login. Each page and the whole run are timed, and a failure names the step.
- VMware inventory: a vCenter or ESXi server with a VMware check lists every host, virtual machine and datastore under Sensors to tick. Hosts and datastores are monitored automatically; virtual machines are ticked by hand.
- Custom reports: choose the sections of a PDF or scheduled report, limit it to one device category, and add a sensor availability table (the share of the period each sensor had no incident open).