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 Connectivity Monitoring and Anomaly Detection Settings tabs.

Connectivity and anomaly alerts are live, first-class features: you turn them on per device (and per sensor) from the device’s detail view — the Connectivity Monitoring and Anomaly Detection Settings tabs — and they show up in Alert History alongside threshold alerts. They are not behind any switch you need to ask for.
Type What it watches How it triggers
Threshold The 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.
Connectivity Whether a device is still sending data. Fires when a device goes silent past its timeout, and again when it comes back online.
Anomaly One 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 numbers For 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.

Method What it does
Unlock by Condition Re-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 Timer Re-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.

5. Message details (optional)

Below the recipients, a Message details section lets you enrich the alert message that goes out by email and SMS. Its help text reads “Optionally add extra details to the alert message sent by email and SMS.” Everything here is off by default.

Set Alert dialog Message details section. Three toggles — Include application link, Include device tags (which reveals a tag picker when it is on), and Include device endpoint — and a Custom message text field limited to 160 characters.
Message details. Add context to the outgoing notification, or a short custom note.
  • Include application link — adds a link back to the application the alert belongs to.
  • Include device tags — turning this on reveals a picker so you choose which of the device’s tags to include in the message.
  • Include device endpoint — adds a link to the device’s endpoint.
  • Custom message — a free-text note (up to 160 characters) added to the alert message.

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 tab in the device’s detail view, and NEQTO.ai creates the underlying alert automatically.

Device detail, Connectivity Monitoring tab. It has a Connectivity alerts toggle (the master on/off), an Email notifications toggle, an SMS 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 four controls:

Control What it does
Connectivity alerts The master switch. When off, this device raises no offline or back-online alerts (in-app, email, or SMS).
Email notifications Also email you when the device goes offline or comes back online. Only applies while connectivity alerts are on.
SMS notifications Also text you when the device goes offline or comes back online. Independent of the email toggle; only applies while connectivity alerts are on, and requires a phone number on your profile with SMS alerts enabled.
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 Anomaly Detection Settings tab.

Device detail, Anomaly Detection Settings tab. Each sensor row shows its attribute name (the raw key, e.g. temperature_celsius), 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 On/Off, Email, and SMS toggles, plus Email every (min) and SMS every (min) interval fields when those channels are on; 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, Email, and SMS per sensor. These 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. Email and SMS are independent of each other and only work while the sensor’s alert is on; SMS also requires a phone number on your profile with SMS alerts enabled.
  • Notification interval per channel — an Email every (min) and a SMS every (min) field, each shown when that channel is on. They set how often a sensor re-notifies you while it keeps reading anomalous, from 15 minutes to 7 days. Leave a field blank to use the default (60 minutes); the value saves when you click away from the field.

Setting names match the sensor’s attribute name exactly (the raw key, such as temperature_celsius or signal_strength_dbm), so they line up with what you see under Device Data.

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:

Status Meaning
New Just fired, not yet looked at.
In Progress Someone is working on it.
Pending Waiting on something else.
Completed Resolved.
Dismissed Acknowledged 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.

Muting Your Own Alert Notifications

Separately from any single alert, you can silence alert notifications to yourself across the whole platform. This is a personal preference on your own account, not a change to the alert rules other people see.

User Settings Alerts section with a Disable all alerts to me toggle. When it is on, a Receive alerts from these applications list of per-application checkboxes appears below, letting the user re-enable notifications for chosen applications.
Settings → Alerts. Mute everything, then opt specific applications back in.

Open Settings and find the Alerts section. Turn on Disable all alerts to me to stop receiving alert notifications across every application. While it is on, a Receive alerts from these applications list lets you tick the applications you still want to hear about, so you can mute everything except the few that matter.

Mute is per person, not per alert. It only changes what you are notified about. The alert still fires and is still recorded in Alert History, and everyone else on the recipient list is notified as normal. To stop an alert firing for everyone, disable the alert itself or use its unlock settings.

Limits and Good to Know

A few non-obvious facts about how alerts behave.

Item Value
Conditions per threshold alert 1 to 10
Unlock conditions per alert Up to 10
Unlock timer minimum 1 minute (field defaults to 60)
Repeat-notification gap (older alert with no unlock set) 24 hours per rule
Connectivity offline timeout 10 minutes minimum
Anomaly sigma multiplier 1 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 Connectivity Monitoring and Anomaly Detection Settings tabs 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.neqto.ai/en/dashboards
Cancel
Open link