Network Management
After upgrading to SolarWinds Platform 2026.2, the new Message Bus service fails to stay running in SolarWinds Platform
The SolarWinds Message Bus Service is not running in 2026.2, which prevents it from processing notifications such as unmanaging node events.
First published date
Last published date
Overview
After upgrading to SolarWinds Platform 2026.2.x, some actions do not work. Manual Unmanaged actions from the Node Details page appear to succeed in the UI, but the node state does not change to Unmanaged.
The SolarWinds Message Bus signals Windows Service Control Manager that it is ready only after it completes startup operations such as restoring streams, restoring consumers, and opening the listening port. Because of that design, startups can exceed the default timeout, especially in slower or restored environments.
It is caused by the SolarWinds Message Bus Service failing to finish startup within the configured startup delay, which leaves Publication/Subscriptions unavailable and prevents the backend execution path from completing.
It happens when the service does not respond within that window, which affects certain features.
Product section
Cause
SolarWinds Message Bus Service is not running because the startup is slow and exceeds the configured startup delay of 30 seconds. When the service does not report readiness within that window, Service Control Manager treats the startup as a failure and stops the service.
In the Message Bus log, you can see how long the service took to start. The Message Bus starts JetStream and spends time restoring many streams and consumers, including SwisPubSub, core, maps, NCM, and others before it begins listening for client connections. In the startup sequence, core alone recovers more than 200 consumers, and the Message Bus does not become ready until 1m8.7387084s has elapsed in this example.
[INF] Took 1m8.7387084s to start JetStream
JetStream recovery and consumer restoration take significantly longer than the configured startup-delay window, so the broker is still initializing when Windows expects it to be fully ready.
Resolution
The corrective action is to increase NATS_STARTUP_DELAY so that the SolarWinds Message Bus Service has enough time to finish JetStream initialization before Windows marks the service startup as failed.
Raise the timeout from 30s to 90s, then start the SolarWinds Message Bus Service, wait for the service to reach the Running state, and retest Unmanaged functionality.
- Increase the machine-level environment variable NATS_STARTUP_DELAY to 90s on the Main Polling Engine.
- Start or restart the SolarWinds Message Bus Service and wait until it reaches Running.
- Confirm that NATS is listening on port 5671 and that the Server is in a ready state in nats.log.
- Retest the manual Unmanage from the Node Details page.
If the issue persists after the startup delay change, collect a fresh set of diagnostics for follow-up analysis.