Introduction to Alerts 2.0

Monitis transition to Alerts 2.0 model

Alerts 2.0 is a new alerting scheme created by Monitis for its monitoring services. It is a conceptually new model that will help you not only understand the problem with the monitored service that has triggered the failure alert but also the severity level of it.

Transition to Alerts 2.0 will be carried out by Monitis phase-by-phase for different monitor types, with the ultimate goal to fully move all monitor types for all users to the new alerting model.

The Phase 1 of transition to Alerts 2.0 was finished in July 2015. The below listed monitor types were covered in the Phase 1 and are currently migrated and working on Alerts 2.0:


– Application monitors:


– Server-Device monitors:


– All custom monitors


Phase 2 of Monitis Transition to Alerts 2.0

Starting from February 5, 2016 Monitis will be rolling out transition to Alerts 2.0 for below listed types:


– Server-Device monitors:

– For new Monitis users starting from February 5, 2016 Alerts 2.0 will be enabled in their accounts for all monitors of the above mentioned types.

– Accounts of existing Monitis users will be migrated by Monitis to Alerts 2.0. Monitis will start rolling out migration of user accounts in scope of the Phase 2 of transition to Alerts 2.0 on February 24, 2016. The migration will be carried out in batches and is expected to finish in April 15, 2016.

See Migration to Alerts 2.0 – Phase 2 for detailed explanations and guidelines about the migration.

You will receive an email notification from Monitis prior to your account migration so that you get ready for the changes.

During the whole transition period for the monitor types not yet migrated to Alerts 2.0 the old alerting model will be in place. Documentation for the old alerting model is available here.


What’s new in Alerts 2.0

In Alerts 2.0 alerting is mapped to the monitor’s state. You define yourself conditions for the monitor of entering either of the two severity level states: CRITICAL or WARNING, by creating respective level thresholds in the monitor (see Thresholds below). The monitor’s state (OK, CRITICAL or WARNING) is reflected in the charts, table views and snapshot views. You can assign then alert rules to your monitor to be alerted whenever it enters CRITICAL or WARNING state or recovers (see Alert Rules below).

Alerts 2.0 introduce a new concept of thresholds in your monitor. Thresholds define the status health of the monitor.

You configure thresholds in the monitor to define conditions for it of entering a problem state.

When adding a new threshold, you assign a severity level (CRITICAL or WARNING) for the problem state that the monitor will enter if the threshold is violated.

Thresholds in some of the monitors have an availability check part to make sure the monitored object is available before taking the measurements. You can define then the metric combination to form the condition in the threshold’s performance part.

For example, you will see it that many of Application monitors have an availability check.


On the other hand, in some Server-Device monitors you will see that there is no availability check in the threshold, but only the performance check because in these monitors the monitored objects are assumed to be always available provided that Monitis Agent (see Downloading and Installing Monitis Agent for Windows and Linux) is up and running on the server.


You can have more than one threshold of the same severity level in your monitor (CRITICAL or WARNING). Your monitor will enter CRITICAL or WARNING state whenever any of the thresholds is violated.


See Thresholds for detailed explanations.


Alert Rules

In Alerts 2.0 alert rules are mapped to the monitor’s state. When adding a new alert rule, select the monitor’s state (CRITICAL or WARNING) to send alerts to your specified contacts upon the monitor entering this state or recovering from it.


See Alert Rules in Alerts 2.0 for detailed information.