FortiMonitor is a holistic, SaaS-based digital experience and network performance monitoring solution which combines monitoring, network incident management, automation, and network configuration management into a single source of truth
Article Id 210974
Description This article describes the nuances of the relationship between breach thresholds and check frequency as well as provides best practice recommendations for the same. A ping check will be used as an example.
Scope Fortimonitor's metrics, alerts and control panel.

When configuring a standard ping check within the FortiMonitor control panel, the first tab offers the user the opportunity to configure the Check Frequency.  Check Frequency determines how much time will elapse before each check is initiated.



The second tab, where breach conditions are configured, allows the user to configure a breach Threshold. Any failure of the configured metric must be 'down' for the entire length of the configured threshold before an incident will be created, with the exception of entering '0' as a threshold. When '0' is entered as the threshold, the metric will generate an incident whenever a failure of any duration is detected.




The best practice recommendations of the FortiMonitor support team are to configure your threshold to '0' for immediate alerting or configure the threshold to match the check frequency.

Underlying Logic

The underlying logic that determines the relationship between check frequency and breach threshold has been provided below. Please note that this specifically applies to public probes - internal OnSight Collectors will only trigger when a result is received.


  • If threshold and check frequency are equal, outages are reported on the subsequent check.
  • If the threshold is greater than the check frequency, it will take check frequency + threshold minutes to alert. This may occur before the next value is received due to the check frequency.
  • If the threshold is 0, outages are reported immediately upon threshold break.
  • If the threshold is lower than check frequency, outages are reported after threshold delay. This may occur before the next value is received due to the check frequency.

As a final note, be aware that a complete separate delay time may be configured in any Alert Timelines that are configured on an instance and that this is a separate process, but one which can add to the overall time before an alert is received.