Upgrading blind: what the SolarWinds 2026.1 HA reports say about release notes

A monitoring platform has one job above all others: be up when everything else is not. So the reports around SolarWinds 2026.1 deserve attention beyond the SolarWinds community.

According to a detailed customer post on r/Solarwinds, 2026.1 ships with a critical issue when High Availability is enabled with a VIP name. Over time, the HA service floods the available port range until it is exhausted, at which point the platform becomes completely unresponsive. A full outage of the monitoring layer, in environments that specifically paid for and configured HA to prevent exactly that. The poster cites a support ticket number, OO-60454, and reports that support confirmed many customers were already affected.

The part that turned this from a bug report into a trust problem: by the customer's account, none of this appears in the 2026.1 release notes. Their phrasing was exact: customers are "upgrading blind."

One bug is an accident. A pattern is a policy.

The same release window produced other reports. After upgrading to 2026.1, some agent-monitored Windows nodes flipped to Critical with WinRM polling failures; the fix eventually surfaced in a support article, found by customers rather than announced to them. Emailed report images broke for users on 2026.1.1, with support unable to resolve it, and a commenter's verdict: "this version is so unstable that when I upgraded to it a bunch of stuff broke," followed by the now-common advice to stay on 2025.x because the new version offers "no benefits or new features" worth the risk.

Separately, an admin documented that NCM config downloads can fail with ACCESS-DENIED without ever appearing as failures in the UI, and published his own SQL alert to catch what the product does not surface. Different subsystem, same theme: the platform's account of its own health cannot be taken at face value.

Every vendor ships bugs. The evaluation criterion is not zero defects. It is what the vendor does with a confirmed, severe, widespread defect: whether it goes into the release notes and known-issues list before customers walk into it, or after.

Release notes are a trust document

Operations teams make a specific bet at every upgrade: that the vendor has told them what they need to know to assess risk. Known-issue disclosure is the entire basis of that bet. When a confirmed platform-down defect is left out, the rational response from customers is exactly what the threads show: freeze on old versions, distrust every future release, and re-read the vendor relationship as adversarial.

That outcome is expensive for everyone. Frozen customers accumulate security exposure. Vendors accumulate a version-fragmented install base. And the operational teams in the middle inherit the job the release notes were supposed to do, scraping Reddit and support portals for the real changelog.

A pre-upgrade checklist that assumes nothing

Until disclosure practices earn trust back, protect yourself procedurally, with any monitoring vendor:

Search the vendor community and support portal for the target version number plus "known issue" before scheduling anything. The real release notes are often there. Wait a cycle: let the .0 release age two to four weeks and watch what surfaces. Snapshot and rehearse rollback for the monitoring platform itself; teams protect production with backups and treat the monitoring server as an afterthought, which is backwards during a monitoring upgrade. And if you run HA, test the failure mode after upgrading, not just the happy path; HA that has never been failed over on the new version is a hypothesis, not a capability.

Where Sensaka fits

Sensaka builds a unified infrastructure operations platform, and we hold a plain position on this: known issues that can cause an outage belong in the release notes, published before customers can hit them, with staged rollout guidance. Self-hosted deployments control their own upgrade timing and change windows.

If part of your team's job has become reverse-engineering your monitoring vendor's changelog, that is a reasonable moment to look at alternatives. We are happy to show you how we handle releases, in writing.

Further reading: explore SolarWinds Alternatives, Multi-Vendor Hardware Monitoring, Sensaka DCOS, and Redfish & IPMI Reference.