v.236 Release Notes

You can now filter alerts based on escalation status on the Alerts page. This enhancement enables you to identify alerts associated with an escalation chain or alerts not linked to any escalation chain, improving alert triage and workflow visibility.

To access this feature, navigate to Alerts and select the Escalation filter from the Filter by field.

For more information, see Filtering Alerts in the product documentation.

The Resource Explorer widget now provides a table visualization layout, in addition to the existing hive layout. The new layout displays resources as a table of resource details, organized by filter and group properties.

This enables you to easily review key details of multiple resources without interactions, and to navigate to Resource Explorer quickly to view additional information on a specific resource in the table.

To access this feature, navigate to Dashboards and add a new Resource Explorer widget, or select Manage on an existing widget. Select “Table” in the Visualization Layout dropdown menu.

For more information, see Resource Explorer Widget in the product documentation.

As LogicMonitor continues to phase out the legacy UI, the New UI Preview switch will be removed from Dashboards, making Dashboards unavailable using the legacy UI, and available in the new UI only. The new UI provides an enhanced user experience, improved performance, and security features.

For more information about this deprecation, including timeline and further updates about the removal, see Upcoming End-of-Life (EOL) for UIv3 Dashboards in LM Community.

For the most up-to-date information about Dashboards, see Dashboards Overview in the product documentation.

If you have any questions or require assistance during this process, contact the Support team or your Customer Success Manager.

You can now use the new Action Notes alert status for custom HTTP delivery requests and PagerDuty incident tickets to send a DiagnosticSource output report as Action note in JSON or plain text format.

LogicMonitor has also introduced the following tokens to configure the payload sent when a DiagnosticSource report is available for an alert:

• ##DIAGNOSTIC_SOURCE_OUTPUT##
• ##DIAGNOSTIC_SOURCE_STATUS##
• ##MESSAGE##

These tokens apply only to the Action Notes alert status for both the custom HTTP and PagerDuty integrations.

For more information, see Custom HTTP Delivery and PagerDuty Integration Setup in the product documentation.

The following Enhanced Script NetScans for various platforms are now Groovy 4 compatible. For more information, see the product documentation:

• VMware vSphere Monitoring
• VMware SD-WAN Monitoring
• Versa SD-WAN Monitoring
• Aruba EdgeConnect SD-WAN
• Cisco Catalyst SD-WAN Monitoring
• Cisco Meraki Monitoring (Legacy)
• Cisco Meraki Monitoring
• Cisco Catalyst Center
• Juniper Mist Monitoring
• Palo Alto Prisma SD-WAN Monitoring

The enhanced lm.data.topo snippet now correctly classifies Cisco 8200 routers as Router Resources. You can view Cisco 8200 routers with the correct resource type in topology mappings, which improves topology accuracy and device identification.

The enhanced Cisco UCS-X NetScan now supports onboarding Cisco UCS Fabric Interconnect resources. You can discover and monitor Fabric Interconnect components as part of your Cisco UCS-X environment, which improves visibility into UCS infrastructure.

For more information, see Cisco UCS X-Series Modular System Monitoring in the product documentation.

The enhanced vmware.vsphere.api snippet improves the helper method for checking the installed version of vCenter. You receive more reliable version detection, which improves monitoring accuracy and reduces version-related discrepancies in data collection.

For more information, see VMware vSphere Monitoring in the product documentation.

LogicMonitor now supports the Action Settings feature, which includes Action Rules and Action Chains. Action Rules enable you to define conditions where an alert can automatically run Action Chains. You can define filters to trigger an Action rule that uses resource group to filter resources, properties, LogicModules, instance data points, and selects the alert severity level. When the conditions are met, the Action rule runs automatically to diagnose and remediate issues. All Action Rules consist of Action Chains that define the stages when the configured DiagnosticSource and RemediationSource can be triggered.

Action Rules have replaced the Diagnostic Rules feature, and your existing Diagnostic Rules have been automatically converted to Action Rules with the same criteria that you specified earlier.

The new feature enables you to do the following:

• Set the foundation for automated remediation with a new framework that supports both diagnostics and remediation in a single workflow.
• Run multiple diagnostics in sequence to investigate issues more thoroughly with a single alert trigger.
• Create flexible, multi-step workflows by defining actions together in a defined order.
• Improve troubleshooting efficiency by automating deeper analysis without manual intervention.

To access Action Rules, navigate to Settings > Action Settings > Action Rules.

To access Action Chains, navigate to Settings > Action Settings > Action Chains.

For more information, see Action Rules Configuration and Action Chains Configuration in the product documentation.

In a future release, LogicMonitor Collectors will no longer support Apache Groovy 2. All official LogicMonitor-provided modules will be compatible with Apache Groovy 4. To support this migration, LogicMonitor is releasing updates to official LogicModules to be compatible with Groovy 4.

As a result of this migration, you must do the following:

• Validate any customized or community-provided modules to ensure compatibility
  For more information about validating your customized modules, see Custom Module Groovy Migration Validation in the product documentation.
• Install a module update for LogicMonitor-provided modules that have compatibility changes released.
  For more information, see LogicMonitor Provided Modules Groovy 4 Migration in the product documentation.
• Update Enhanced Script NetScans to Groovy 4 compatible scripts.
  For more information, see “Enhanced Script NetScans Now Groovy 4 Compatible” in the Modules section of the Release Notes.

For more information on the timeline of this migration, see Apache Groovy 2 End-of-Life Milestone Public Announcement.

The LogicMonitor EA Collectors https://www.logicmonitor.com/release-notes/ea-collector-39-100 , https://www.logicmonitor.com/release-notes/ea-collector-39-200 , https://www.logicmonitor.com/release-notes/ea-collector-39-300 and https://www.logicmonitor.com/release-notes/ea-collector-39-400 are now available and use Groovy 4 instead of Groovy 2. In accordance with Collector versioning, a stable EA version is designated as an optional general release (GD).
The GD Collector release planned for April 13, 2026, LogicMonitor GD Collector 39.004, will use Groovy 4 instead of Groovy 2.

When running a module using Apache Groovy 4, and using the groovy.json.JsonSlurper(), the following exception was fixed with the LogicMonitor Collector version 36.200 or later:

When running a module using Apache Groovy 4, and using java.util.Date.format(), the following exception was resolved with the LogicMonitor Collector version 35.400 or later.

exception:groovy.lang.MissingMethodException: No signature of method: java.util.Date.format() is applicable for argument types: (String) values: [yyyy-MM-dd'T'HH:mm:ss z]

When running a module using Apache Groovy 4 with legacy classes in your script, the following exception can be thrown:

java.lang.RuntimeException: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed

To mitigate this issue, migrate to JPMS-compliant package names. Making this change does not break backward compatibility with Groovy 2.

For example, the following script uses legacy classes:
import groovy.util.XmlSlurper
import groovy.util.XmlParser
def xmlSlurper = new XmlSlurper()
def xmlParser = new XmlParser()

You can replace the legacy classes with JPMS-compliant package names in Groovy 4 to resolve the exception, similar to the following:
import groovy.xml.XmlSlurper
import groovy.xml.XmlParser
def xmlSlurper = new XmlSlurper()
def xmlParser = new XmlParser()

In Apache Groovy 4, the behavior of the push() method for the List class is reversed. In Apache Groovy 2.4, the push() method would add an item to the list, in Apache Groovy 4 push() will work on the first item of a List.
// v4 Behavior
def numbers = [1, 2, 3, 4]
numbers.push(5)
println numbers
// OUTPUT: [5, 1, 2, 3, 4]

// v2.4 Behavior
def numbers = [1, 2, 3, 4]
numbers.push(5)
println numbers
// OUTPUT: [1, 2, 3, 4, 5]

To mitigate this issue, migrate to using add() in place of push():
def numbers = [1, 2, 3, 4]
numbers.add("5")
println numbers
// OUTPUT: [1, 2, 3, 4, 5]

When running a module using Apache Groovy 4, the behavior of the pop() method is reversed. In Apache Groovy 2.4 the pop() behavior would remove the last item in a list, in Groovy 4 pop() will remove the first item in a list.

// v4 Behavior
def numbers = [1, 2, 3, 4]
println numbers.pop()
// OUTPUT: 1

// v2.4 Behavior
def numbers = [1, 2, 3, 4]
println numbers.pop()
// OUTPUT: 4

To mitigate this issue, migrate to using remove() in place of pop():
def numbers = [1, 2, 3, 4]
println numbers.remove(numbers.size() - 1)
// OUTPUT: 4

When running a module using Apache Groovy 4, and the module includes an invalid type parameter for a data structure, the module throws the following exception:
java.lang.RuntimeException: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:

When running a module using Apache Groovy 4, the following exception can be thrown when using the GroovyScriptHelper to incorporate LogicMonitor snippets in your script:
exception:groovy.lang.MissingPropertyException: No such property

To mitigate this issue, adjust the way the class is imported, similar to the following:

import com.santaba.agent.groovy.utils.GroovyScriptHelper
import com.logicmonitor.mod.Snippets
def modLoader = GroovyScriptHelper.getInstance(GroovySystem.version).getScript("Snippets", Snippets.getLoader()).withBinding(getBinding())

You can now include the following new columns in an Alert report:

• Threshold Set At—Displays the DataSource, instance, or resource group value
• Alert Trigger Value—Displays the metric value that triggered the alert and matches the value displayed on the Alerts page, including precision and rounding behavior

The new columns are supported in the Report Preview and generated reports. Existing saved Alert reports do not automatically include the new columns unless you add them.

To access this feature, navigate to Reports and add an Alert report.

For more information about how to configure an Alert report, see Alerts Report in the product documentation.

You can now include custom host properties in the Alert Forecast Report so you can deliver client-ready reports that combine projected alert trends with relevant resource metadata. This enhancement enables you to analyze forecasted alert growth by business unit, environment, customer, or any other custom property—enabling you to identify which segments are driving increases in alert volume and where proactive threshold tuning or remediation may be required.

The custom host properties display as custom columns alongside historical alert counts and forecasted alert totals in exported reports, enabling you to correlate projected alert activity with key organizational or technical attributes.

To access this feature, navigate to Reports, and add an Alert Forecast report.

For more information, see Alert Forecast Report in the product documentation.

You can now configure the number of results that display in a Resource Metric Trends report. This enables you to display the number of DataSources based on the selected time range, with options to display the top 5, 10, 25, 50, or 100 results. In addition, you can display all results, which includes all available data based on the Resources or Resource Groups defined in the report. This flexibility enables you to focus on the most relevant resources driving metric trends, while still having the option to view the complete dataset when deeper analysis is required.

To access this feature, navigate to Reports, and add a Resource Metric Trends report.

For more information, see Resource Metric Trends Report in the product documentation.

You can now configure recurring monthly SDT on the last day of every month for the Monthly (on a specific day) frequency. Irrespective of when the month ends (that is, on the 28th, 29th, 30th, or 31st), you can select “on last day” from the Day dropdown menu. The system automatically identifies the last day of the month and sets the SDT. This provides greater flexibility for planning maintenance and enables precise scheduling for maintenance windows across varying month ends without manual adjustment.

To access this feature, navigate to Resources > select a resource > Schedule SDT. Select the From/To configuration, choose the Monthly (on a specific day) frequency, and then select “on last day” from the Day dropdown menu.

For more information, see Resource SDT in the product documentation.

As LogicMonitor commits to modernizing the platform and ensuring improved performance, security, and long-term scalability to provide a seamless API experience, access to the API v1 and v2 will no longer be made available for new LogicMonitor accounts. If you are currently using API v1 or v2, your access will not be impacted. You may continue use without interruption.

The Keep Me Signed In security setting now defines the interaction between session duration and the Enable Persistent Session user-level setting. When you toggle the Enable Persistent Session switch, a user is excluded from the session timeout configured in the Keep Me Signed In setting.

The current Keep Me Signed In setting allows session durations of up to 400 days or no limit. To overcome this security risk and to prevent long or infinite sessions, LogicMonitor now limits the session duration.

You can now define the session duration in the Keep Me Signed In Days field with supported values ranging from 1 to 30 days. A value of ‘0’ day keeps the session active until you log out manually. Existing customers with Keep Me Signed In session limit set to 0 will continue to retain the current configuration without modification. In future if the policy changes, your Customer Success Manager (CSM) will notify you in advance of any required updates.

LogicMonitor now provides greater visibility into session management, and ensures predictable, and secure access for service accounts and continuous-display users, such as Network Operations Center (NOC) environments.

To access this feature, navigate to Settings > Security.
To access Enable Persistent Session for user accounts, navigate to Settings > Users and Roles > Users.

For more information, see Keep Me Signed In and Adding a Role in the product documentation.

In a future release, LogicMonitor will discontinue support for legacy LM Container builds and Argus versions 5, 6, 7, and 8. If you are running these versions, upgrade to a supported LM Container release to continue receiving updates and support.

The latest LM Container releases provide:

• Improved monitoring accuracy using updated and actively maintained code paths
• Latest security patches and compliance updates for modern Kubernetes environments
• Ongoing compatibility with newer Kubernetes versions and container runtimes

For more information about this deprecation, including timeline details and further removal updates, see Upcoming End of Life (EOL) for Legacy Versions 5, 6, 7, and 8 for Legacy LM Container & Argus in the LM Community.

If you have any questions or need assistance during the migration, contact the Support team or your Customer Success Manager.