What changed, release by release.

v3.3.12 OCTOBER 2026

Fixed

• Linux collection over SSH with a sudo password. When sudo asked for a password, its prompt text was written in front of the collected data and nothing landed. The collector now finds the data behind any prompt text, and the prompt itself is no longer printed.
• Primary user on Debian 13. A footer line of the login history was counted as a login, so a computer with little history showed a wrong primary user.
• Job status when the identity check could not run. A check that timed out, returned nothing or was refused used to be reported as an identity mismatch. It now shows its own status, and such jobs count as failed on the Dashboard, the asset list and the Run page.
• Service heartbeats. Each background service now reports on its own schedule, so the Services page flags a stuck service instead of showing an old healthy stamp.
• Role changes. Changing a user's role moves the user to the matching built-in group. An administrator can no longer remove the administrator role from their own account, and the last active administrator cannot be demoted.
• Users & Access. Custom groups now show as badges in the Users table.
• Investigate. The Status filter now applies to attribute-change rows too.
• AI assistant. Running a script on several computers at once reported every created job as an error; it now reports the jobs correctly.

New

• Evaluation virtual machine. You can now register on the website and download a virtual machine with Octotor already installed, for Hyper-V, VMware or VirtualBox. See Evaluation VM.
• Scheduled tasks skip computers that are known to be offline. A task created from now on carries the option Skip targets the online monitor reports offline, ticked by default. Such targets get no job in that run, and the run record says how many were skipped. Existing tasks keep running against every target until you tick the option.
• Unmatched Microsoft 365 sign-ins. Sign-ins whose account exists in Microsoft 365 but not in Octotor are counted in the sync summary and listed under Investigate ▸ Unmatched sign-ins, each row with a reference number. Link a row to a person or ignore it, one or many at a time. The AI assistant can list them.
• Install and upgrade. A new install turns the host firewall on by default: only SSH (the port the SSH service listens on), the web port and ping are accepted from the network. The local AI model is no longer installed unless you ask for it, which makes a new install about ten gigabytes smaller; it can be added later. After each upgrade, image sets older than the previous version are removed from disk and the freed space is reported; the current and the previous version stay for a rollback.

Changed

• The shipped software carries no development comments, test files or build recipes any more.

After upgrading

• Three small schema migrations run at start-up; the upgrade takes a database backup first, as always.
• Open each scheduled task that should skip offline computers and tick the new option; new tasks have it on already.
• The first upgrade with this version removes the old image sets from disk. On a box that has been upgraded many times this frees tens of gigabytes.
• Nothing here is licensed separately.

v3.3.11 SEPTEMBER 2026

New

• The Customer Overview replaces the Dashboard. The page Octotor opens on now shows every customer as one of four states — needs action, watch, OK, or no data yet — worst first, with one card each carrying the state, how long it has held, how many items need action and how many are to watch. One click opens a single customer with its counters, its topic tiles and its recent events. Every tile says what it measured, of how many, and the real date and time of the reading behind it, and links into the asset list, the alerts or the event history already filtered to that customer and topic. The menu entry is still called Dashboard. Help ▸ Dashboard — the Customer Overview walks through it, and the Customer Overview page explains it with worked examples.
• Daily Status — seven days at a glance. Each customer and each tile carries seven squares, one per day, each holding the worst state reached that day. A run of red squares separates a problem that has been standing all week from one that started this morning.
• "Needs action now", and marking something as known. A panel lists every open problem across the customers you are allowed to see. Click I'm aware on a row, leave a note and choose how long it stands (7 days by default, 90 at most): the item leaves the needs-action count, its tile turns yellow instead of red, and the row stays listed under Acknowledged — still listed, not counted with who marked it and until when. Everyone sees the same mark. It clears itself when the problem goes away or the date passes. An item that stands on an alert is one record in two places: marking it here marks the alert, and marking the alert counts here.
• A number on every action, and handling several at once. Each row in the panel carries a number such as #41 that belongs to that problem while it stays open, so it can go in a ticket or be read out on a call and mean the same thing to whoever opens the page. Numbers run in one series across the installation. A problem that clears and returns later takes a new number. Tick several rows — or Select all — and mark or withdraw them together, answering for the note and the period once. A mixed selection is not refused: each button acts on the rows it can and then reports what it did and what it left alone.
• Tiles you build yourself. A custom tile counts any group of assets you can already filter on the asset list, per customer, with a colour rule of your own — good when nothing matches, watch from N, needs action from M, or information only. A preview and a per-customer match table follow every change before you save. Custom tiles count toward a customer's state and can be marked as known like anything else.
• Pin tiles per customer. Unpin a topic that does not apply to one customer and it drops to a strip at the bottom, stops counting toward that customer's state and stops putting rows in the panel. Its alerts are untouched. Pinning is shared and audited.
• Settings ▸ Dashboard. One place for the landing view (automatic, always the cards, or always one customer), which tiles appear and in what order, the disk and offline-computer thresholds, how stale a reading may be, how often the page reloads, whether the panel is shown on each view, and whether tile links open in a new tab.
• The AI assistant can read the overview and answer in plain words — which customers need action, why one is red, what has been wrong this week. It sees only the customers your login may open, and it can read but not change.

Changed

• The old Dashboard — Recent Jobs, Active Protocols and the System Status block — is replaced by the Customer Overview. System Status now lives on the Services page, which already carried the same health information.
• Tile links open in a new tab by default, so the overview stays where it was. Switch it off under Settings ▸ Dashboard.

After upgrading

• Nine schema migrations (710 to 718) run at start-up; the upgrade takes a database backup first, as always.
• The Daily Status squares start empty and fill in from the upgrade onward. The history is written once an hour, so the strip shows a full seven days after a week of running. Nothing is missing — there is no record of the days before the upgrade.
• Open Settings ▸ Dashboard once and check the thresholds against how you work: the disk percentages, the share of a customer's computers that may be offline before it counts as a site problem, and how old a reading may be before a tile is treated as having none. They colour tiles only — to be notified about something, keep or add an alert rule.
• If your team prefers links to open in the same tab, untick the new-tab option in the same section.
• Nothing here is licensed separately: the overview, marking items as known and custom tiles are included in every plan.

v3.3.10 17 SEPTEMBER 2026

New

• Light backup collector for Veeam servers with a long history. On a server that holds years of restore points the full collector could not finish: the whole-history reads alone took 15 to 17 minutes and every run was cut off with nothing to show. A second script, windows/veeam-vbr-collect-light.ps1, reads the newest run of every job only and finishes in about two minutes on such a server. It writes the same backup values on the protected computers and the same job counts on the backup server. What it does not do: update Backup Jobs — Failed Recently, mark a removed computer "Not protected", or list runs that happened between two light runs. Schedule it every few hours next to the nightly full run; where the full run can never finish, use the light one alone. The backup server gains Backup Data — Last Full Collection so you can see when the full collector last ran. Help ▸ Backup Collector ▸ "Full or light collector?" explains both.
• Tell the backup collector what Veeam calls a computer. A virtual machine is often backed up under its name in the hypervisor, which can differ from the computer's host name, and some Veeam servers record no guest DNS name for it. Such a computer never received its backup values and was listed under Backed-Up Items With No Asset after every run. Every computer now has the manual attribute Name in the backup software (Attributes tab, BACKUP group): type the name exactly as Veeam shows it, and the next run matches the item to that computer. The names a run could not match are also written into the run's event on Investigate (category backup, "unmatched names:"), so you can search for a name and see which run reported it. Help ▸ Backup Collector ▸ "How computers are matched" walks through it.
• Alert rules can remind you while an alert stays open. Until now a rule notified once when an alert fired and again when it resolved; a backup that kept failing every night sent nothing after the first message. Every rule now has the option Notify again while still breaching, on by default, throttled by the rule's cooldown. New rules default to one reminder a day; existing rules still at the seeded 4-hour cooldown are moved to 24 hours so nobody is flooded. Each reminder names the attempt and how long the alert has been open, and reminders that could not be delivered are counted too, so a broken channel shows up.

Fixed

• Pages start once. Thirteen pages ran their start-up twice, so every request they make at open was sent twice. Alerts Admin and the Scheduler also asked for the "affected assets" count one request per rule or task; they now ask once for the whole list. Opening Alerts Admin went from 132 requests to 13, which also stops the "too many requests" errors seen with many rules.
• Backup jobs tab: the Log and View job output buttons stayed inside the card on narrow screens and with long job names; times are shown compact with the full date on hover.
• New Rule: before a name is typed, the affected-assets panel shows a plain hint instead of a raw error message.
• Help ▸ Custom notification templates lists every placeholder, including the reminder ones.

After upgrading

• Five schema migrations (705 to 709) run at start-up; the upgrade takes a database backup first, as always.
• For every computer listed under Backed-Up Items With No Asset on a backup server: open the computer, Attributes tab, Edit attributes, and type the name Veeam shows into Name in the backup software. The next collector run picks it up.
• Reminders are on for every rule. Open Alerts ▸ Admin and untick Notify again while still breaching on any rule that should stay silent.
• For a Veeam server where the full collector never finished: create a scheduled task with windows/veeam-vbr-collect-light.ps1, schedule 10 */4 * * *, Timeout 240 seconds. Where the full collector finishes, add the light task next to it.

v3.3.9 10 SEPTEMBER 2026

Fixed

• Backup monitoring works with Veeam Backup & Replication 13. Veeam 13 ships its PowerShell module for PowerShell 7 only, so on a Veeam 13 server the collector could not load it and landed nothing. The collector now detects the installed Veeam version and runs its Veeam part under PowerShell 7 on version 13 and newer; on version 12 and older nothing changes. If PowerShell 7 is missing on a Veeam 13 server, the run ends with a plain message that names the install (aka.ms/powershell) instead of an empty result. Every reason a load failed is reported with the run.
• Backup servers with a long history finish in minutes instead of never. Restore points are now read once for the whole server and sorted per machine in memory. On a server holding a year of history (thousands of restore points) the run went from never finishing to about three and a half minutes.
• A virtual machine whose name in the hypervisor differs from its host name is matched to its computer. Veeam records the guest's DNS name on each restore point; the collector now passes it on, so a machine named for example FS-02_replica in Hyper-V lands on the asset FS-02. When Veeam holds two entries for the same computer, the newest backup wins. Machines for which Veeam holds no guest name keep matching by their VM name, as before.
• Help ▸ Backup monitoring explains the PowerShell 7 requirement, the recommended timeout for large servers, what to do when a run fails or lands nothing, and how matching works.

After upgrading

• No schema migration. The upgrade takes a database backup first, as always.
• On every Veeam 13 backup server, make sure PowerShell 7 is installed (the run tells you when it is not).
• For a backup server with a long job history, open the collector task in the Scheduler and set Timeout (sec) to 900. Small servers are fine at 240.

v3.3.8 9 SEPTEMBER 2026

Fixed

• Scheduled task settings now apply to the job that runs. The Timeout (sec), Auto-proceed if connectivity check fails, sudo, identity-verification override and protocol you set on a scheduled task were saved but never reached the worker that executes the job, so every scheduled job ran with the global defaults (for example the 30-second SSH timeout). They now travel with the job. Every job transcript prints the limit it runs under, and a job that is cut off by its timeout says which field to raise.
• A backup job that failed and is idle again is no longer missed. The backup server now also shows Backup Jobs — Failed Recently: every job that had a failed run in the last 24 hours (or since the previous collection, when that is longer ago), even if the job is idle or green again by the time Octotor collects. A new critical rule, Backup job failed recently on server, alerts on it.
• On the Backup jobs tab, choosing a result filter that matches nothing kept the filter buttons hidden; they stay visible so you can return to All.
• On the Attributes tab, backup dates showed the raw stored text with the time-zone offset; they show as local date and time.
• On a scheduled task, the identity-verification override panel saved five of its eight settings; the WinRM Identity Gate and both Default Gate choices are now saved too.

After upgrading

• Two schema migrations run automatically at first start (a new column on the jobs table; the new backup count, its name list and the new rule). The upgrade takes a database backup first.
• Open your backup collector task in the Scheduler and set Timeout (sec) to 240 (Help ▸ Scheduler ▸ Task Options). If you raised the global SSH timeout as a workaround, you can set it back to 30.
• The rule Backup job failed recently on server is enabled on install. Its first collection looks back 24 hours.

v3.3.7 9 SEPTEMBER 2026

New

• Backup monitoring. Octotor reads the job history of a Veeam Backup & Replication server and writes the result onto the computers it protects: last successful backup, last result, overdue, and the last warning or error text. Five alert rules fire when a backup fails, ends with a warning, or is late. A Backup jobs tab on the server shows every run with the Veeam log lines of failed items, and the AI assistant can answer questions about backup state. Pro and Enterprise plans. Read how it works and how to set it up.
• Jump hosts for ordinary SSH jobs. Until now a jump host (bastion) attached to an asset was only used by appliance recipes. Every SSH job on that asset now goes through the jump host: scripts, commands, collectors and scheduled tasks, on any device type, including Windows hosts with OpenSSH. The reachability check and the identity check before a job also run through the jump host. WinRM jobs are not routed through a jump host; such a job fails with a message that says so. Assets attached to a jump host are excluded from offline alerts, because the Octotor server cannot reach them directly to check their status; threshold alerts on collected values keep working.
• Build date in the health check. /api/health and the Services Status page now show when the running images were built.

Fixed

• On the Run page, Continue anyway and Abort after a failed reachability check now reach the worker that holds the job; before, a job could stay parked until it timed out.
• A job stopped by the operator is recorded as cancelled. Before, a stopped SSH job could be recorded as done with exit code 0, and a collector could parse its cut-off output.
• A job whose connection closed without an exit status is recorded as failed instead of done.
• Deleting a credential that a jump host logs in with, or deleting a jump host that assets are attached to, now tells you what depends on it before you confirm.
• Viewers no longer see the Clear Duplicate button on an asset.

After upgrading

• Three schema migrations run automatically at first start (backup attributes, backup job history table, the five backup alert rules). The upgrade takes a database backup first.
• New setting Settings ▸ Backup Collector ▸ Switch on threshold alerts for the computers the collector finds (default Yes) and Settings ▸ Maintenance ▸ Backup job history (days) (default 90).
• Backup monitoring needs a Pro or Enterprise plan. Existing Pro and Enterprise licence files keep working; nothing has to be reissued. Community installs do not include backup monitoring.
• To start monitoring backups: mark the Veeam server, link a credential, schedule the collector. The feature page has the five steps.

v3.3.6 4 SEPTEMBER 2026

New

• Every data disk is monitored. The collector scripts now report every fixed data disk on a server (size, free space, free percent, label), fullest first, instead of one "secondary disk" slot that could silently track the wrong disk on servers with two or more data disks. One catch-all rule on the fullest data disk replaces per-slot rules; alert messages name the disk; the asset drawer lists every disk and the list view shows the fullest one.
• Guided tours on every page. A Tours menu in the top bar (25 tours in 4 groups, opening the live demo) and a per-page Tour button, which you can switch off under Settings.

Fixed

• SNMP-observed recoveries now raise and resolve availability alerts like ping does.
• Computers discovered from Active Directory or Entra get their operating-system family at creation, so scheduled collection tasks pick them up without a manual step.
• A stale cached status can no longer hide the real status stored in the database.
• Removed a repeated log line in the background worker; in-app seat wording matches the plans page.

After upgrading

• One schema migration runs at first start. If you had alert rules on the old "secondary disk" attributes, replace them with one rule on Lowest free space on any data disk; the old attributes now mean the literal D: drive.

v3.3.5 18 AUGUST 2026

Changed

• Source-hygiene release: comments, test fixtures, example strings and distribution-script defaults were cleaned up before the public release of the source. No product behaviour changed and no schema migration runs.
• Community plan wording: 10 seats, where a seat is a user, a computer, or a managed network device.

After upgrading

• Nothing to do.