Applications Systems

Submitting any assigned Application monitor with custom threshold fails silently in SolarWinds Platform 2026.2

Clicking Submit (or Save and Continue) when editing any Application Monitor just causes a brief grey flash, no error is shown, and no changes are saved.

First published date

7/27/2026 7:45 AM

Last published date

7/28/2026 3:31 PM

Overview

In SolarWinds Platform 2026.2, when editing an assigned Application Monitor (e.g. AppInsights, standard component, etc.):

  • Open Edit Application Monitor for any Application Monitor.
  • Scroll down, optionally make changes (or make no change at all).
  • Click Submit or Save and Continue Working.

Observed behavior:

  • The page briefly flashes grey and reloads the Edit Application screen.
  • Going back into the application, none of the changes are saved.
  • The issue occurs:
    • For all Applications on the server (SQL, AD, IIS, …).
    • Even when logged in with a full admin account.
  • Browser Developer Tools (Network tab) show the save request (for example POST /Orion/APM/Admin/Edit/EditAitsm/SaveApplication) returning HTTP 500 (Internal Server Error) in Network tab.

Product section

Server Application Monitor

Cause

The failure is not caused by a permissions issue, browser problem, or by a designed limitation on editing the Application monitors.

Instead, it is triggered by a very specific data condition on Component thresholds:

  • The affected application has at least one component where:
    • A threshold override exists at the application level (IsTemplate = 0), and
    • Baseline calculation has been enabled and completed for that threshold, so baseline date fields are populated.

Representative row from APM_Threshold for an affected component:

  • IsTemplate = FALSE
  • ThresholdName = 'StatisticData' (example)
  • ComputeBaseline = TRUE
  • UseBaseline = FALSE
  • BaselineFrom / BaselineTo / BaselineApplied contain timestamps
  • BaselineApplyError is blank

When an Application with such a baseline-enabled override is edited, the server attempts to serialize the threshold settings as part of the save operation. Due to the regression from ScriptIngnoreAttribute, that serialization step throws an error before the request is processed, causing:

  • The SaveApplication call to return HTTP 500.
  • The UI to simply “flash and reload” with no error message.
  • The inability to:
    • Save any changes to that Application, and
    • Even re-inherit settings from the template (because inheriting also requires a successful save).

As soon as at least one threshold override with baseline data exists on an Application, that entire application’s Edit/Save path is broken.

Resolution

A fix for this issue is planned for a future release of the SolarWinds Platform. In the meantime, the workaround is to clear the baseline metadata on affected Application-level threshold overrides in the database.

1. (Optional but recommended) Identify affected thresholds

Use this query to list all Application-level thresholds that have baseline data and can trigger the issue, including node name and component details:

-- Scripts are not supported under any SolarWinds support program or service.
-- Scripts are provided AS IS without warranty of any kind. SolarWinds further
-- disclaims all warranties including, without limitation, any implied warranties
-- of merchantability or of fitness for a particular purpose. The risk arising
-- out of the use or performance of the scripts and documentation stays with you.
-- In no event shall SolarWinds or anyone else involved in the creation,
-- production, or delivery of the scripts be liable for any damages whatsoever
-- (including, without limitation, damages for loss of business profits, business
-- interruption, loss of business information, or other pecuniary loss) arising
-- out of the use of or inability to use the scripts or documentation.

SELECT
    n.Caption        AS NodeName,
    a.ID             AS ApplicationID,
    a.Name           AS ApplicationName,
    atpl.Name        AS ApplicationTemplate,
    c.ID             AS ComponentID,
    c.Name           AS ComponentName,
    t.ThresholdName,
    t.Warning,
    t.Critical,
    t.ComputeBaseline,
    t.UseBaseline,
    t.BaselineFrom,
    t.BaselineTo,
    t.BaselineApplied,
    t.BaselineApplyError,
    t.IsTemplate
FROM dbo.APM_Threshold t
JOIN dbo.APM_Component c
    ON c.ID = t.ID
JOIN dbo.APM_Application a
    ON a.ID = c.ApplicationID
JOIN dbo.APM_ApplicationTemplate atpl
    ON atpl.ID = a.TemplateID
LEFT JOIN dbo.Nodes n
    ON n.NodeID = a.NodeID
WHERE t.IsTemplate = 0
  AND t.ComputeBaseline = 1
  AND (
       t.BaselineFrom IS NOT NULL
    OR t.BaselineTo IS NOT NULL
    OR t.BaselineApplied IS NOT NULL
    OR t.BaselineApplyError IS NOT NULL
  )
ORDER BY
    n.Caption,
    a.Name,
    c.Name,
    t.ThresholdName;

Save/export this result so you have an audit of what will be changed.

 

2. Bulk-clear baseline for affected Application thresholds

Important: Back up the SolarWinds Platform database first or ensure a recent backup exists.

The following script clears the baseline metadata for all Application-level thresholds that match the pattern above:

 

-- Scripts are not supported under any SolarWinds support program or service.
-- Scripts are provided AS IS without warranty of any kind. SolarWinds further
-- disclaims all warranties including, without limitation, any implied warranties
-- of merchantability or of fitness for a particular purpose. The risk arising
-- out of the use or performance of the scripts and documentation stays with you.
-- In no event shall SolarWinds or anyone else involved in the creation,
-- production, or delivery of the scripts be liable for any damages whatsoever
-- (including, without limitation, damages for loss of business profits, business
-- interruption, loss of business information, or other pecuniary loss) arising
-- out of the use of or inability to use the scripts or documentation.

SET NOCOUNT ON;
SET XACT_ABORT ON;

BEGIN TRY
    BEGIN TRANSACTION;

    UPDATE t
    SET
        t.BaselineFrom        = NULL,
        t.BaselineTo          = NULL,
        t.BaselineApplied     = NULL,
        t.BaselineApplyError  = NULL
    FROM dbo.APM_Threshold t
    WHERE t.IsTemplate = 0
      AND t.ComputeBaseline = 1
      AND (
           t.BaselineFrom IS NOT NULL
        OR t.BaselineTo IS NOT NULL
        OR t.BaselineApplied IS NOT NULL
        OR t.BaselineApplyError IS NOT NULL
      )
      AND EXISTS (
          SELECT 1
          FROM dbo.APM_Component c
          JOIN dbo.APM_Application a
              ON a.ID = c.ApplicationID
          WHERE c.ID = t.ID
      );

    SELECT @@ROWCOUNT AS RowsCleared;

    COMMIT TRANSACTION;
END TRY
BEGIN CATCH
    IF @@TRANCOUNT > 0
        ROLLBACK TRANSACTION;

    THROW;
END CATCH;

 

What this does:

  • Leaves the numeric threshold values (Warning/Critical) intact.
  • Clears the baseline date / applied / error fields that trigger the serialization bug.
  • Keeps the record as an application-level override (IsTemplate = 0).

3. Validate

  1. On the DB, re-query a known affected component to ensure BaselineFrom, BaselineTo, BaselineApplied, and BaselineApplyError are now NULL.
  2. In the web UI:
    • Open Edit Application Monitor for one of the previously affected Applications.
    • Click Submit (with or without changes).
    • Confirm:
      • The request no longer returns HTTP 500.
      • The page navigates back correctly.
      • Changes are now persisted.

 

Please note:

  • This issue only impacts Applications that have baseline-enabled threshold overrides at the application level.
  • Standard SAM application monitors and Templates without such overrides are not affected.
  • Once the product fix for this is applied in a future release/hotfix, this SQL workaround should no longer be necessary, but it is safe to leave the cleaned-up threshold rows as is.