Release LoadGen Api, Appliance and MCP Server: 1.0.0.11891

Updated June 11, 2026 09:02

LoadGen General

New Service Level Management foundation (LG058 / LG059). This release lands the first usable slice of enterprise SLO / SLA management end-to-end. You can now define services and objectives, freeze them into immutable versions, attach business-hours policies and explicit maintenance or incident exclusion windows, map objectives to services, and pick a dedicated ServiceLevels datasource (SQL Server or PostgreSQL, with encrypted connection-string handling). Snapshots, recalculations, exports, alerts, and read APIs for active snapshots, per-objective health, violation diagnostics, and budget queries are all available under /service-levels/.... An on-demand evaluator writes append-only snapshots that respect frozen objective versions, business hours, and exclusions, and an in-process scheduler (configurable through the API, with a manual run trigger) keeps results fresh automatically. The slice also covers tenant filtering, an ACL store with deny-wins semantics, sensitive-path audit logging, JSON / CSV exports with a download endpoint, retention configuration with periodic rollup compaction, persisted alert rules wired into the existing Slack / email / webhook fanout, anonymous public status pages (gated by the public-status-pages license module), and a Load Testing source adapter so Load & Performance datasources can feed the same SLI contract as Uptime and Monitoring data.

[#8468] Saving a managed PowerShell uptime check from the wizard quietly lost the chosen script, and the worker then reported that the check had no script to execute. The API was dropping the script id on the wire because the request model still only carried the older script-path field. The uptime check create, update, and Test payloads now carry the script id end-to-end, so the wizard's Test step runs the picked script the first time and saved checks execute the correct script.

[#8662] Operators can now remove individual backup archives from Infrastructure → Appliance → Backups without resorting to SSH. A new trash-icon button in the appliance UI deletes the selected archive and reports clearly when the selected backup no longer exists.

[#8552] Web and Core test runs no longer come back empty without warning. Result ingestion now flows through the same worker pipeline as Full Agent and Citrix tests, so result packets land in the configured sink instead of being silently dropped when the API-side sink had not started. Operators also get a single, throttled status-bar error the first time a batch is rejected during an execution, so a misconfigured or unavailable ingestion worker surfaces in the UI instead of only in the support bundle. The behaviour now covers Core / Web and Full Agent / Citrix paths uniformly, and a follow-up in the same release hardens the data-sink session lifecycle so concurrent sessions shut down cleanly without disrupting one another.

[#8628] The SessionSight Heatmaps page rendered 0 total — No pages found even with plenty of recorded sessions. The browser tracker was not tagging emitted events with a viewport category, so the page's desktop filter matched nothing. Click, drag, rage-click, dead-click, and scroll-depth events now carry a mobile / tablet / desktop viewport classification derived from window width, so heatmaps populate immediately for newly captured sessions on the default 7-day, threshold 5, Desktop view.

[#8694] A customer with two LG050 entitlements bound to the same appliance saw the Infrastructure → Licensing card flip the Load Testing module off because a zero-seat renewal placeholder was masking the active 50-seat entitlement. The license picker now prefers entitlements with non-zero seats before tie-breaking on expiry date, so the Load & Performance Testing module stays unlocked whenever a real seat count is available. Single-entitlement and all-non-zero customers are unaffected. The licensing payload also now includes an explicit module-code field alongside the friendly module name so support bundles are unambiguous.

[#8662] The appliance agent now supports per-row backup deletion from the Infrastructure → Appliance → Backups UI. It deletes the selected archive from disk, logs the operation, and reports clearly when the requested backup no longer exists. Existing Create, List, Download, Import, Restore, and Schedule operations are unchanged.

[#8693] When you typed a build number that does not exist into System → Updates → Appliance Agent and clicked Update, the resulting toast used to show a raw stack trace. The appliance now returns a clean Build {number} not found. Please check the build number and try again. message instead. Other update failures (transport errors, server-side problems) still surface the existing generic error so support diagnostics are unchanged, and the full exception is still recorded in the appliance log for support bundles.

[#8676] On a freshly deployed appliance, saving an email in My Profile could fail with The appliance preferences API rejected the value. because the preferences storage shipped in a state the appliance could not write to. Fresh appliances now set up that storage correctly on the first save, so the My Profile flow goes through on the first attempt, and existing appliances self-recover on the first successful save.

[#8660] Applying a custom certificate through the HTTPS Setup Wizard left Grafana and InfluxDB still serving their built-in self-signed certificates because the custom certificate was never applied to the monitoring subdomains. The wizard now applies the uploaded certificate and key to the Grafana and InfluxDB subdomains as well, so all three FQDNs serve the same trusted certificate. Existing appliances self-heal on the next agent restart with no operator action required.

[#8665] Changing the InfluxDB admin password from the Infrastructure → Appliance → Services tab failed with User 'admin' not found in InfluxDB. whenever the actual InfluxDB user had been renamed or initialized with a non-default name. The appliance agent now falls back to querying InfluxDB with the saved admin token to discover the correct user, completes the password change, and persists the discovered username back to the appliance configuration so subsequent changes do not need the fallback. This also closes the related sign-in failure reported as #8664. When even the fallback cannot identify the user, the error message now points operators at the username setting and the InfluxDB discovery endpoint for self-diagnosis.

[#8657] Clicking Remove on a hosts entry in System → Network → Hosts Entries → Manage failed with Failed to remove hosts entry: Agent returned 400 (Bad Request) on every attempt, because the agent could not read the hostname from the removal request. Removals now succeed, and any genuine agent errors come through with their real message instead of an empty 400.