Receiving too many meaningless LogicMonitor alert notifications can ultimately lead to people ignoring important alerts. On the other hand, not receiving a key alert could result in service downtime or even an outage. The key to avoiding both of these undesirable situations is to tune datapoint thresholds for your unique environment.

LogicMonitor does much of the work for you by setting default static thresholds based on published documentation and KPIs, industry best practices, research, years of experience, and customer feedback. This means that, for the majority of resources you monitor via LogicMonitor’s DataSources, alerts are triggered right out of the box.

However, it is impossible to set datapoint thresholds that suit every use case. To ensure that your alerting implementation is sufficient, without being noisy, you can continuously refine the default datapoint thresholds for the DataSources you are using. This is called tuning thresholds and it is discussed in detail in Tuning Static Thresholds for Datapoints.

Note: Other datapoint settings (in addition to static datapoint thresholds) that can impact alert noise include dynamic thresholds, alert trigger intervals (i.e. how many consecutive polling cycles a threshold must be exceeded in order for an alert to trigger), alert clear intervals (i.e. how many consecutive polling cycles datapoint values must remain below threshold before an alert clears), and No Data alert behavior (i.e. should the absence of expected data trigger an alert?). As discussed in Datapoint Overview, these settings are configured from the global DataSource definition.


The following demonstration shows how to tune static thresholds at the global and instance levels. Although this demonstration features an older version of the LogicMonitor platform, you may still find that the general information provided is very helpful in your understanding of threshold tuning.

Next steps:

After you’ve tuned datapoint thresholds to best fit your environment, you should add users and roles and then proceed to configure your alert routing to ensure that the right people are notified when an issue occurs.

In this Article: