Alert Limitations

This article outlines some of the most commonly experienced alert limitations. Specific alerts may come with the following limitations:

• For general alerts, Alerts are processed once every hour. Therefore, it can take up to 60 minutes after an event occurs before the user receives a notification. 

  For example, an alert is defined to send an email notification if a device does not register within 15 minutes. The device de-registers at 6:05 and does not re-register until 6:20. The email alert notification for this device is sent to the user at 7:00 since alerts are analyzed at the beginning of the hour.

• For alerts with a traffic policy applied, traffic is NOT automatically unblocked at the beginning of a new alert interval.

  For example, an alert is defined to block packet traffic if usage exceeds 5 MB in one month. At some point during the current month, the device exceeds 5 MB and the packet traffic is blocked. At the beginning of the next month, packet data remains blocked until the block is manually removed by either editing the device on the Devices tab or through the AerAdmin Traffic Policy API.

• For alerts-based data blocking, blocking relies upon receiving continue records or stop records from the underlying data network.

  Data usage may exceed the trigger threshold because these data feeds only occur periodically, but blocking occurs once Alerts detect the exceeded threshold. The time period between data feeds varies between products and depending on the device behavior, it is possible for a significant amount of data to be consumed beyond the alert threshold.

  Some products may take as long as 75 minutes for usage threshold detection:

  • For Fusion NA, Fusion Global, and Fusion Global HD products, this period is 11 minutes.
  • For Dual-Mode A-LH and Global SIM, this period is 75 minutes.
• For maximum threshold alerts, there may be an additional latency of up to 20 minutes before an event is detected in the system.

  For example, if a device reaches a maximum threshold at 11:50, the system may not detect this event until 12:10. A notification for this alert will be sent to the user at 1:00, when alerts are processed at the beginning of the following hour.

• For minimum threshold alerts, notifications are always sent at the end of the indicated time interval. The complete time duration must pass before determining whether usage was below the defined threshold.

  For hourly minimum threshold alerts, the user receives the alert after each full hour has passed. For daily minimum threshold alerts, the user receives the alert after each full day has passed (GMT). For month-to-date minimum threshold alerts, the user receives an alert at the end of the month (after the last day of the month, GMT).

  Note: For hourly minimum threshold alerts, there may be an additional latency of up to 15 minutes before an event is detected in the system, resulting in the trigger of invalid minimum alerts.

• For Aeris alerts, any changes to the API Key causes the publish operation to fail until the API Key cache is refreshed. API keys are refreshed every 24 hours at 00:05, GMT.
• For specific product limitations, see the table in Alert Threshold and Triggers.