Account metrics monitoring
The Account metrics monitoring feature enables proactive monitoring and alerting capabilities on your account. It allows you to define alarm rules that monitor specific conditions and trigger notifications through configured notification channels when those conditions are met.
Supported alarms
| Alarm type | Functional category | Trigger type | Description |
|---|---|---|---|
actionSuspended |
Routing |
event |
This alarm is triggered when a routing action is automatically suspended following a prolonged malfunction of this action (e.g. the http push error rate is too high for 7 consecutive days) |
messageDeliverySuccessRatio |
Routing |
metric evaluation |
This alarm is triggered when the success ratio of message delivery to your servers deteriorates on a routing action. The success ratio is calculated as the percentage of messages successfully delivered (at the first try or after retry) over the total number of messages to be delivered within a specified evaluation window. For more details on the underlying counters, see the message delivery counters section below. To avoid false alarms on low-traffic or newly created routing actions, the delivery ratio is only evaluated when at least 20 messages have been processed within the evaluation window. If this threshold is not reached, the alarm is not triggered regardless of the delivery outcome. |
Event based alarms
Event-based alarms are triggered immediately when a specific event occurs within the platform.
{
"enabled": true,
"type": "actionSuspended",
"name": "Automatic suspension",
"notifications": {
"notificationChannelIds": [
"default"
]
}
}| Field | Description |
|---|---|
enabled |
Whether the alarm rule is enabled or not |
type |
Defines which event is monitored |
name |
User-defined name for the rule |
notifications |
Notifications configuration |
notifications.notificationChannelIds |
IDs of notification channels that define the recipients of the alarm |
Metric based alarms
Metric-based alarms are triggered when a metric meets a specific condition.
{
"enabled": true,
"type": "messageDeliverySuccessRatio",
"name": "Delivered message degradation",
"throttle": {
"muteDuration": "P1D"
},
"trigger": {
"condition": {
"comparisonOperator": "lessThanOrEqualTo",
"threshold": 90.0,
"evaluationWindow": "P1D"
}
},
"notifications": {
"notificationChannelIds": [
"default"
]
}
}| Field | Description |
|---|---|
enabled |
Whether the alarm rule is enabled or not |
type |
Defines which metric is monitored |
name |
User-defined name for the rule |
throttle.muteDuration |
The duration for which notifications for the same alarm are muted after being sent. During this period, additional notifications for the same alarm will not be sent, even if the alarm is repeatedly triggered |
trigger.condition |
Conditions that must be met to trigger the alarm. |
trigger.condition.comparisonOperator |
The type of operator used for comparison (e.g. ≤) |
trigger.condition.threshold |
The threshold value that the metric must meet to trigger the alarm (as a percentage in the example) |
trigger.condition.evaluationWindow |
The time window (as an ISO 8601 duration) over which the data will be aggregated and evaluated |
notifications |
Notifications configuration |
notifications.notificationChannelIds |
IDs of notification channels that define the recipients of the alarm |
Alarm evaluation
Data is aggregated and evaluated over hourly-aligned buckets:
-
Alarm rules are evaluated once every hour, during the first 30 minutes of the hour.
-
Each evaluation considers data from a window that ends exactly at the beginning of the current hour.
-
For example, an evaluation at 15:15 with a 24-hour window uses data from 15:00 (previous day) to 15:00 (current day).
This diagram illustrates how an alarm rule with a 24-hour sliding evaluation window is processed. At the bottom, message delivery rate shows normal traffic (~10 req/s), then drops during an incident period (shaded in red), and eventually recovers with retry traffic. Multiple delivery ratio timelines show how each hourly evaluation captures a different 24-hour slice—ratios progressively degrade as more of the incident falls within the window. The alarm triggers when ratios fall below 95%, and notifications are sent accordingly.
Alarm muting
To prevent notification overload, you can configure your alarm rule with a mute duration:
-
After an alarm triggers and a notification and a alarmEvent are sent, subsequent notifications and alarmEvents for the same alarm are suppressed during the mute period.
-
The alarm continues to be evaluated, but notifications are not sent until the mute duration expires.
-
Once the mute period ends, if the alarm condition is still met, a new notification will be sent.
This diagram illustrates how the mute duration feature prevents notification flooding. With a 1-hour evaluation window and interval, the system evaluates the delivery ratio every hour. When the ratio drops to 80% (below the 90% threshold), an alarm triggers and a notification is sent. The 6-hour mute duration then suppresses subsequent notifications, even though the alarm condition persists across evaluations.
Metric definitions
Message delivery counters
For message delivery success ratio alarms, the following counters feed the delivery ratio. They are calculated per routing action and aggregated per hour.
HTTP Push and Azure Event Hubs routing actions
| Counter | Description |
|---|---|
processed |
Total number of messages to be delivered through this routing action (i.e. already delivered, still pending or failed) |
delivered |
Number of messages successfully delivered on the first attempt |
deliveredWithRetry |
Number of messages successfully delivered after one or more retry attempts |
The message delivery ratio is defined as:
100 × (delivered + deliveredWithRetry) / processed
FIFO routing actions
| Counter | Description |
|---|---|
processed |
Total number of messages to be delivered through this routing action (i.e. pushed to the FIFO queue, regardless of whether they were consumed through MQTT) |
delivered |
Number of messages delivered through a MQTT SUB connection |
The message delivery ratio is defined as:
100 × delivered / processed
Metric timestamping
A message is counted in the hourly bucket corresponding to the time the Live Objects platform collected it (e.g. the field created of a data message) triggered it (e.g. the timestamp of a device status change event), not when it was delivered to your application or when a final delivery failure was established — refer to routed messages for other message types.
This means that the metrics for a given hour may include messages that were delivered (or failed) in a later hour.
|
As a consequence, the delivery ratio for a past evaluation window may increase retroactively after an alarm is triggered. If failures were caused by a transient issue (e.g. your HTTP endpoint was temporarily unavailable), messages that were retried and successfully delivered will be retroactively attributed to their original hourly bucket — so inspecting the same evaluation window later (e.g. via the Live Objects web portal) may show a higher ratio than when the alarm was triggered, potentially reaching 100%. Despite this, the incident can still be confirmed via the Live Objects web portal. For HTTP Push and Azure Event Hubs routing actions, two indicators remain reliable even after the ratio has recovered:
|
Default alarm rules
A set of default alarm rules is automatically provisioned on your account. These default rules use the default notification channel to alert the main user of your account.
Default alarm rules can be modified or disabled according to your needs.
Notification channels
Notification channels define the target endpoint (email only for now) used to deliver alarm notifications.
{
"name": "OPS Team",
"language": "en",
"emails": {
"to": [
"to1@example.com",
"to2@example.com"
],
"cc": [
"cc@example.com"
],
"bcc": [
"bcc@example.com"
]
}
}| Field | Description |
|---|---|
name |
User-defined name for the notification channel |
language |
Language to use for this notification channel |
emails |
Email recipients configuration |
emails.to |
List of primary recipient email addresses |
emails.cc |
List of CC recipient email addresses |
emails.bcc |
List of BCC recipient email addresses |
Alarm events
Alarm events have the same logic of muting as notifications for account metrics monitoring and are integrated with LiveObjects 'Message routing' capabilities. Whenever Live Objects triggers an alarm related to account metrics monitoring, it generates an alarm event. This event is subject to the same muting logic. This event is routed to the destination defined in the action policy. For the alarm event format and examples, see Alarm event.