Start Free Trial

Alerts

Alerts watch your device data and tell you when something needs attention. You define a condition, NEQTO.ai checks every reading against it, and when the condition is met it fires an alert and notifies the people you chose. Every alert that fires is recorded in Alert History so you can track and triage it.

The mental model: an alert is a rule (which devices, which attribute, what condition) plus a notification list (who to tell). Data arrives, the rule is evaluated, and matching events become notifications and history entries.
Lifecycle diagram: a device reading arrives, NEQTO.ai evaluates it against the alert's conditions, and when the conditions are met the alert fires. Firing sends notifications by email and SMS, writes an event to Alert History with a severity and status, and optionally locks the alert until an unlock condition or timer is satisfied.
How an alert flows: reading in, condition check, fire, notify, then a tracked event in Alert History.
Naming note: the UI says Attribute and Endpoint; the API and support docs call these data type and data source. They are the same things. This page uses the UI words.

Alert Types

NEQTO.ai evaluates three kinds of alert. You build threshold alerts yourself in the Set Alert dialog; connectivity and anomaly alerts are managed per device from the device’s Alert Properties tab.

Connectivity and anomaly alerts are live, first-class features: you turn them on per device (and per sensor) from the device’s Alert Properties tab, and they show up in Alert History alongside threshold alerts. They are not behind any switch you need to ask for.
TypeWhat it watchesHow it triggers
ThresholdThe current value of one or more device attributes.Fires when your conditions are met, for example temperature Greater than 30. This is the default type in the Set Alert dialog.
ConnectivityWhether a device is still sending data.Fires when a device goes silent past its timeout, and again when it comes back online.
AnomalyOne sensor reading versus its own physical limits and learned statistical range.Fires when a value leaves the normal range. Configured per sensor on the device.
About “history” alerts: an older alert type compared an attribute against its own recent history (increased / decreased / average over the previous 24 hours, week, or month). The platform still understands history alerts, but the Set Alert dialog now creates threshold alerts. If you open an old history alert it is shown as threshold.

Creating a Threshold Alert

Open Alerts and click the + button (its tooltip reads Create Alert) to open the Set Alert dialog. The dialog has four parts: title and severity, trigger conditions, unlock conditions (optional), and notifications.

Alerts list page titled Alerts. A list of cards, one per alert, shows the alert's name, a status switch with an Active/Inactive badge, a severity badge, a lock indicator when the alert is locked, the devices it covers, the attributes it watches, and a per-card actions menu, plus a search box and a + add-alert button.
The Alerts list. Each card is one rule; the switch enables or disables it, and the actions menu has Edit and Delete.

Each row shows a Status switch with an Active or Inactive badge, a Severity badge, a lock icon when the alert is currently locked (paused), the devices it covers, and the attributes it watches. The per-row actions menu (the ⋮ button) offers Edit and Delete — each only appears if you have the matching permission. There is no separate “lock” action in the menu; locking is controlled by the alert’s unlock settings, described below.

1. Title and severity

  • 1
    Enter an Alert Title (required, up to 100 characters; letters, numbers, spaces, and the basic punctuation - _ ( ) , . : are allowed).
  • 2
    Pick a Severity: Info (blue), Warning (yellow, the default), or Critical (red). Severity is a label for triage and filtering; it does not change when the alert fires.
Set Alert dialog top section: an Alert Title text field and a Severity dropdown showing Info, Warning, and Critical, each with a colored dot (blue, yellow, red).
Title and severity. Severity is for organizing and filtering, not for triggering.

2. Trigger conditions

A condition is one row: a device, one of its attributes, an operator, and a value. Add up to 10 conditions.

Set Alert dialog Trigger conditions section. Each condition row has a device selector, an attribute selector, the word is, an operator dropdown, and a value input that shows the attribute's unit. A Condition logic radio group with AND (All) and OR (Any) appears once there is more than one condition, plus an Add condition button.
Trigger conditions. Build one or more device-and-attribute rows, then choose AND or OR.

The available operators depend on the attribute’s data type:

For numbersFor text
Greater than (greater)Contains (contains)
Greater than or equal to (greater_equal)Exact match (exact_match)
Less than (less)Does not match (no_match)
Less than or equal to (less_equal)
Equal to (equal)
Not equal to (not_equal)
AND vs OR: when you have more than one condition, a Condition logic control appears. AND (All) fires only when every condition is true at once. OR (Any) fires when at least one is true. Conditions are re-checked as each device’s readings arrive.

3. Unlock conditions (optional)

Unlock conditions control how an alert re-arms after it fires. When a method is on, the alert fires once, locks (goes quiet), and stays locked until it is allowed to re-arm, which prevents a flood of notifications for the same ongoing problem. The dialog turns Unlock by Timer on by default with a 60-minute timer, so out of the box an alert waits before it can fire again; turn both methods off if you want it to lock until you re-enable it by hand.

Set Alert dialog Unlock Conditions section with two toggles: Unlock by Condition, which reveals its own device/attribute/operator/value condition rows, and Unlock by Timer, which reveals an Unlock after (minutes) number input. Helper text explains that whichever method is met first will unlock the alert.
Unlock conditions. Turn on either method, or both; the first one satisfied re-arms the alert.

There are two unlock methods. Turning on either one enables locking automatically.

MethodWhat it does
Unlock by ConditionRe-arms when a condition you define becomes true (same device / attribute / operator / value rows as triggers, up to 10). Use the opposite of your trigger, for example trigger when temperature is above 30, unlock when it drops below 25.
Unlock by TimerRe-arms automatically after a set number of minutes (minimum 1, the field defaults to 60). The countdown starts when the alert locks.

If both are on, the alert unlocks as soon as either the condition is met or the timer expires, whichever comes first.

Why this matters for notifications: while an alert is locked it will not notify again, even if the condition stays true. With condition-based unlock there is no extra wait once it re-arms; with a timer, the timer length is the minimum gap between repeat notifications. If you turn both unlock methods off, the alert fires once and then stays locked until you re-enable it by hand. An older alert that has no unlock setting at all falls back to a 24-hour minimum gap between repeat notifications for the same rule.

4. Notifications

Set Alert dialog Notifications section. A single Notifications toggle controls delivery. When it is on, a Notification Recipients list appears (account or application users plus external contacts shown as chips) added via an Add Recipient menu offering Add User and Add External, and a Notification Groups picker with an Add Notification Group button.
Notifications. Choose individual users, ad-hoc external contacts, and reusable notification groups.

The dialog has a single Notifications toggle. Turn it on, then choose who hears about it:

  • Users from your account or application, added with Add Recipient → Add User. Each is notified by email.
  • External contacts, added with Add Recipient → Add External. You give an email address and/or a phone number and toggle Email Notifications and SMS Notifications per contact. Phone numbers use E.164 format, for example +1234567890.
  • Notification Groups, reusable recipient lists (see below).
Channels. The dialog delivers by Email and SMS (the Notifications toggle’s own help text says it sends email and SMS when an alert is triggered). External contacts are notified per the Email and SMS toggles you set on each one. There is no separate in-app or webhook control in this dialog: every alert that fires is still written to Alert History, which is where in-app activity shows up, and although a Webhook label exists in the platform’s data, there is no webhook setting in the alert dialog, so treat webhooks as not available here.

Click Create to save. Editing an existing alert opens the same dialog (titled View Alert) with a Save button.

Notification Groups

A Notification Group is a reusable recipient list, so you do not re-pick the same people for every alert. Groups are scoped to an application: open an application and go to its Notification Groups page (alongside that application’s Alerts).

Notification Groups page inside an application, titled Notification Groups with the description Create mailing lists to easily assign notification recipients to alerts. A table lists each group's Name, Description, and member count, with a Create Group button.
Notification Groups. Build a list once, then attach it to any alert.
Create Notification Group dialog with Name and optional Description fields and a Members section. Members are added as Add User (account users) or Add External (an email and a phone for SMS, with Email Notifications and SMS Notifications toggles per member).
A group’s members can be account users or external email/SMS contacts.
  • 1
    Click Create Group, give it a Name and an optional Description.
  • 2
    Add members: Add User for account users, or Add External for an email and/or phone number with per-member Email and SMS toggles.
  • 3
    In any alert’s Notifications section, use Add Notification Group to attach the group. When the alert fires, everyone in the group is notified.

Connectivity Alerts

A connectivity alert tells you when a device stops sending data. You do not build these in the Alerts list; each device has its own Connectivity Monitoring card on the device’s Alert Properties tab, and NEQTO.ai creates the underlying alert automatically.

Device detail Alert Properties tab, Connectivity Monitoring card. It has a Connectivity alerts toggle (the master on/off), an Email notifications toggle, an Offline Timeout field in minutes (minimum 10), and a Save Changes button.
Per-device connectivity monitoring. Set the timeout to match how often the device actually reports.

The card has three controls:

ControlWhat it does
Connectivity alertsThe master switch. When off, this device raises no offline or back-online alerts (in-app or email).
Email notificationsAlso email you when the device goes offline or comes back online. Only applies while connectivity alerts are on.
Offline Timeout (minutes)How long to wait with no data before treating the device as offline. The minimum you can enter is 10 minutes.
How “offline” is decided. A device is considered connected while data keeps arriving. If nothing is received within its Offline Timeout, it is marked offline and the alert fires. The shortest timeout you can set is 10 minutes. NEQTO.ai re-checks for silent devices on a short, regular schedule , and a short per-device cooldown limits how often the same device can notify, so a flapping connection does not spam you . A device that reports only once an hour will read as offline between reports unless you raise its timeout to cover the gap.

When a device that had gone offline starts sending data again, a back online recovery notification is sent (subject to the same cooldown), telling you how long it was down.

Anomaly Detection

Anomaly detection flags a single reading that is abnormal, without you setting a fixed number. It learns each sensor’s normal range from its own history. Configure it per sensor on the device’s Alert Properties tab.

Device detail Alert Properties tab, Anomaly Detection Settings card. Each sensor row shows its name, a Sigma Multiplier input between 1 and 5, the current statistical range Mean ± Sigma × StdDev, a Save button, and a help button. Sensors that have finished warm-up and have an anomaly alert also show an On/Off alert toggle and an Email toggle; sensors still learning show a Warm-up in progress label instead.
Per-sensor anomaly settings. Sigma controls how far from normal a reading must be before it counts as an anomaly.

How it works

Detection has two layers:

  • Absolute limits. Hard physical bounds per sensor type: temperature in Celsius is bounded at -40 to 85 °C (Fahrenheit -40 to 185 °F), humidity and battery at 0 to 100 %, and signal strength at -100 to -20 dBm. A reading outside these is always a critical anomaly. Unrecognized sensor types have no absolute limits.
  • Statistical range. Once a sensor has collected enough readings to finish its warm-up , NEQTO.ai computes its mean and standard deviation and flags readings outside mean ± (sigma × standard deviation). A statistical anomaly is rated warning when the reading is more than 3 standard deviations from the mean, otherwise info.

What you configure

  • Sigma Multiplier per sensor, from 1 to 5 (the input steps in 0.1), default 2. It is the width of the “normal” band: 2 sigma is about a 95% confidence interval. Higher sigma means a wider band, so fewer false alarms but a higher chance of missing a real anomaly. Change it and click Save on that row.
  • On / Off and Email per sensor. These two toggles appear only once that sensor has finished warm-up and its anomaly alert exists; until then the row shows a note that the controls become available after the alert is created. The Email toggle works only while the sensor’s alert is on.
Anomaly Detection Help dialog showing a bell-curve normal distribution chart for one sensor, with a green Mean line and two orange dashed lines at minus sigma and plus sigma marking the lower and upper statistical thresholds, a Mean / StdDev / Sigma / Confidence summary, and a sigma slider from 1 to 5 with confidence percentages.
The Anomaly Detection Help dialog visualizes the normal range. Drag or click the slider to widen or narrow the band, then Save.
Warm-up: per-sensor statistics only appear after a device has been sending data for a while. A sensor still gathering data shows a Warm-up in progress state and cannot raise statistical anomalies yet. Once warm-up finishes, the row shows the sensor’s live mean and standard deviation and the current statistical range, and the On/Off and Email toggles become available.

Alert History

Every time an alert fires it creates an event. The Alert History page is where you review, triage, and clean up those events.

Alert History page titled Alert History with the description View and manage all alert events and their status history. Event cards show the alert name, message, device, severity color, and a status badge. Filters across the top cover Severity, Status, and a Date Range picker, with select-all and delete controls.
Alert History. Filter by severity, status, and date, then work through events.

Event status

Each event carries a workflow status you can update as you handle it:

StatusMeaning
NewJust fired, not yet looked at.
In ProgressSomeone is working on it.
PendingWaiting on something else.
CompletedResolved.
DismissedAcknowledged and set aside.

Status changes are recorded, so each event keeps a history of who moved it where.

Filtering and cleanup

  • Filter by Severity (All Severities, Info, Warning, Critical), by Status (All Statuses, New, In Progress, Completed, Pending, Dismissed), and by a Date Range picker.
  • Use the select-all checkbox to pick events and Delete selected in bulk, or set a date range and Delete by date range. Both ask for a confirmation, and both need the alert-delete permission.
Live sync: the alerts shown across the app refresh on their own whenever the platform pushes an update over its live connection, and immediately after you create or edit an alert, so the list and counts stay current without a manual reload.

Limits and Good to Know

A few non-obvious facts about how alerts behave.

ItemValue
Conditions per threshold alert1 to 10
Unlock conditions per alertUp to 10
Unlock timer minimum1 minute (field defaults to 60)
Repeat-notification gap (older alert with no unlock set)24 hours per rule
Connectivity offline timeout10 minutes minimum
Anomaly sigma multiplier1 to 5 (steps of 0.1), default 2
  • Severity is a label, not a trigger. Use it to filter and prioritize in Alert History.
  • Match operators to the data. Numeric attributes get numeric operators; text attributes get Contains / Exact match / Does not match.
  • Use unlock conditions to stop alert fatigue. Lock on the way up, unlock on the way down, or after a timer.
  • SMS needs opt-in. An account user only gets SMS if they have a phone number and have opted in; external contacts are notified per the toggles you set on them.
  • Connectivity and anomaly alerts are per device, configured from each device’s Alert Properties tab rather than from the Alerts list.

Leave a Reply

Your email address will not be published. Required fields are marked *

Start Free Trial

Open external link

You’re leaving Claude to visit an external link:
https://stg-app.env-neqtoai-staging.kinsta.cloud/en/dashboards
Cancel
Open link