Network Management

Opsgenie alert processing via HTTP/s Post issue after upgrading to SolarWinds Platform 2026.2

Opsgenie was not processing HTTP/HTTPS POST alert data sent from SolarWinds after the upgrade. The issue is related to TLS 1.3 compatibility on the Opsgenie side. Although the SolarWinds ActionExecution alert logs show that the HTTP/HTTPS POST action completed successfully, and Wireshark confirms that the TLS handshake was accepted by the third-party endpoint, Opsgenie does not process the submitted data when the connection uses TLS 1.3.

First published date

7/17/2026 3:22 PM

Last published date

7/17/2026 3:22 PM

Overview

The current issue is caused by third-party processing limitations when the HTTP/HTTPS POST action uses TLS 1.3. Although TLS 1.3 is the preferred protocol from a security perspective, Opsgenie is not processing the submitted data successfully when that protocol is negotiated. As a workaround, forcing the connection to use TLS 1.2 restores functionality.

There are two available approaches: disable TLS 1.3 at the operating system level or limit the change to SolarWinds services through advanced configuration. The best option depends on whether other applications on the same server require TLS 1.3.

Product section

Orion Platform

Cause

Before the upgrade, the SolarWinds application running on HCO 2025.1 was limited to TLS 1.2, which was the supported protocol at that time.

After the upgrade, TLS 1.3 became supported. As a result, outbound connections, including the Alert Action HTTP/HTTPS POST, may now negotiate TLS 1.3 depending on the operating system capabilities.

Because Windows Server 2022 has TLS 1.3 enabled by default, applications that support TLS may attempt to use TLS 1.3 whenever it is available.

Resolution

You may disable TLS 1.3 at the operating system level through registry changes. Once TLS 1.3 is disabled, the connection falls back to TLS 1.2, which allows SolarWinds to send data in a format that Opsgenie is able to process successfully.

This confirms that the issue is not with the SolarWinds alert action itself, but with third-party processing when TLS 1.3 is used.

Available Options

There are two possible ways to address this issue:

  • Option 1: Disable TLS 1.3 at the operating system level via registry tweaks:

    • Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Client]
"DisabledByDefault"=dword:00000001
"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Server]
"DisabledByDefault"=dword:00000001
"Enabled"=dword:00000000

  • Option 2: Disable TLS 1.3 through advanced configuration Settings in SolarWinds

Both options should provide the same result. The difference is in scope:

  • Option 1 affects all services on the server, including operating system services, and limits them to TLS 1.2

  • Option 2 affects only SolarWinds services

If other applications or services on the server require TLS 1.3, then Option 2 is the better approach. If no other service depends on TLS 1.3, then Option 1 can remain in place.

Security Consideration

TLS 1.3 is generally recommended because it provides stronger encryption and improved security. However, due to the current third-party limitation, falling back to TLS 1.2 is necessary to maintain compatibility with Opsgenie.

Rollback

These changes can be reverted at any time by re-enabling TLS 1.3 in the registry, or by removing the registry entries, and then restarting the server.

Recommendation

Coordinate with Opsgenie to understand why the submitted data is not being processed when the HTTP/HTTPS POST action uses TLS 1.3.

At this time, using TLS 1.2 is an effective workaround to restore functionality while maintaining secure communication.