Release LoadGen Api, Appliance and MCP Server: 1.0.0.12324

LoadGen General

• No general changes in this release.

LoadGen Api

• New — Uptime dashboards. You can now build your own saved boards of uptime checks instead of only seeing the whole fleet: pick the checks that matter, choose how many tiles sit on a row, and mark a board as the page you land on. Boards can be private or shared, an administrator can set one as the appliance-wide default, and each user can pin their own landing page (including the built-in All checks view). A board references checks rather than copying them, so renaming a check follows automatically. Refreshing a small board is also much cheaper — it now queries only the checks on the board rather than every check on the appliance.
• [#9526] The Full Agents, Core Agents and VDI Agents pages now flag an outdated agent version: each agent's reported version is shown next to the version it should be on, with an up-to-date / updates-available verdict. The comparison is done server-side against your appliance's release channel, so an agent that is current on a stable-pinned appliance is not falsely flagged.
• [#9598] Fixed uptime maintenance windows that recur: a window created in a non-UTC time zone opened hours late (it used the wall-clock time against UTC), and a window crossing midnight — such as 23:00–01:00 — never activated at all. Windows are now evaluated in their own time zone (surviving daylight-saving changes) and overnight windows work. Note: on a non-UTC appliance, existing recurring windows will now open at the time they were actually set to, rather than hours later.
• [#9604] Fixed an uptime check's availability sparkline reporting a large number of missed checks on the newest bar the moment a check was created (for example "Checks: 10 / 10 passed, Missed: 86"). The current, in-progress hour is no longer billed for checks that haven't come due yet; closed bars are unchanged.
• [#9537] Fixed LoadGen Studio showing "0 workloads" for a load profile whose users all point at a workload that other profiles also use. Workload usage now lists each consuming profile separately with its own user count (the appliance's own workload usage badge was under-reporting shared workloads for the same reason).
• [#9518] An "Agent activation failed" error at test start now names why and which endpoint it failed against — for example that the agent did not respond, or did not become ready — instead of only naming the agent. (Note: activation does not perform a desktop logon; the Run-As logon happens at a later preparation step.)
• [#9527] Fixed remote agent installs over WinRM failing when the target already had an agent running ("Access to the path is denied"). The agent's service and any running processes from the payload are now stopped before the files are replaced, this now also covers Core Agent and Insight installs, and a file locked by something else (an antivirus scanner, an open editor) is now reported by name instead of failing the whole install opaquely.
• [#9400] A VDI no-dial-back failure now records whether any LoadGen VDI Agent has ever reached the platform, so a support bundle collected later still shows whether the agent is installed and able to connect — pointing at the launcher rather than the session host. (The remaining reported case on one launcher is still under investigation.)
• Security — dependency update. Bumped SSH.NET 2024.1.0 → 2026.0.0 to clear a high-severity advisory (CVE-2026-48798, path traversal) flagged by the image vulnerability scan. Applies to both the API and MCP Server images; no behavioural change.

LoadGen Appliance

• [#9601] Fixed the PostgreSQL Setup action failing with an error that blamed a manual password edit the operator never made. The appliance now recovers the working credential itself and rotates it, so Setup completes — no data is lost and nothing is re-initialized. New appliances can no longer get into this state.
• [#9530] Fixed Grafana → Configure Datasource still failing with a 401 after the previous fix, on appliances where Grafana's stored admin password had drifted. The appliance now also recovers the credential from its own configuration history, and the in-product Grafana password change works again. The Services tab now also distinguishes "could not read the datasource list" from "there are none".
• [#9521] Fixed downloading the API log from Appliance → Debug aborting in the browser (reported as a connection error) while other files downloaded fine. A log that is actively being written now downloads completely — you get the log as of the moment you clicked.
• Longer forensic history on new appliances. Container logs are now size-bounded and the system journal retains weeks rather than about a day, so evidence for an incident is still available when it is investigated. Applies to newly built appliance images.

LoadGen Launcher Appliance

• [#9302] Fixed Windows guest activation reporting "No Key Management Service (KMS) could be contacted" as a final failure on a guest that activated correctly moments later — the guest's network was still coming up after the reboot. Activation now retries a contact failure before giving up, while a genuine licensing problem still fails immediately with a clear reason.

LoadGen MCP Server

• Security — dependency update. The MCP Server image carries the same SSH.NET 2026.0.0 update as the API image (see the API section).