Troubleshoot alerts you did not receive

Symptom, cause and fix for an alert that should have fired and did not.

An alert crosses five gates between the machine and the person, and IoTFlows reports a failure at none of them. A rule with an empty subscriber list looks identical to one that works. So the method is to walk the path in order rather than to guess, and to rule out the cheap causes before the ones that need somebody else's phone.

Every field named here is set in Event Notifications on one machine, see Set alert rules for a machine.

Start here: four checks

Where an alert can fail: rule disabled, empty subscriber list, threshold, channel permission, and the destination itself.A diagram of the path an alert travels, drawn as six stages down the left with five numbered failure points beside the arrows between them. The stages read: the machine stops, a condition happens on the floor; the event fires, the stop passes the rule's threshold; a channel carries it, email, push, SMS, log, work order; IoTFlows sends it, to each subscriber or to the destination; the destination accepts it, inbox, phone, or chat channel; somebody reads it, the alert did its job. The five failure points read: 1, threshold, the stop is shorter than the minutes set on the rule, so no event ever exists. 2, the channel is off, that column's switch is off on this machine, or the device type does not show the section at all. 3, empty subscriber list, the column is on, but nobody is subscribed to this event type, and email, push and SMS fail here silently. 4, the channel gate, push permission denied on the phone, no verified phone number for SMS, or a webhook revoked at the platform. 5, the destination, delivered, but sitting in a spam folder or a chat channel nobody reads. A note across the bottom reads: nothing in IoTFlows reports a failure at any of the five, so work down the path in order.

Check the subscriber list before the channel. Switching Email on for an event type does not email anybody. The rule sends to the list attached to that event type on that machine, and an empty list fails silently, which is the single most common cause of a rule that looks correct and reaches nobody.

Work these four in order. Each rules out a cause the ones after it cannot explain.

1. Did the event fire at all? Turn Log on for that event type and read the machine's Event Alerts list on its Health tab, see Review and dismiss machine events. Nothing there means the condition never met its threshold, and no channel was ever asked to carry anything.
2. Is the channel on for this event type? Open the row in Event Notifications and read across its six columns. Each column is an independent switch, and it is set per event type, not per machine.
3. Is anyone subscribed? Click the cell in the Email, Push or SMS column of that row. A dashed circle with a + means the list is empty, see Email, push and SMS subscriber lists.
4. Can the destination accept it? Push needs an OS permission, SMS needs a verified phone number on the recipient's account, and an integration needs a webhook that still exists at Slack, Teams or Discord.

Then jump to your symptom.

Nobody got the email

Confirm the event fired, then open the Email cell on that row. Almost every "the alert never arrived" report ends here, with an empty list or a list holding one person who has since left.

The list belongs to the event type. Subscribing Maria to Machine Down on the Haas VF-2 tells her nothing about Device Offline on the same machine, and nothing about Machine Down on the Doosan 2600 beside it. Repeat the subscription on every event type and every machine she is responsible for.

If the list is right, the email is delivered and unseen rather than unsent. Search the recipient's spam folder and any rule that files mail from unknown senders, then add the sender to their allowed list.

Push never arrived

Push has two switches the product cannot see: the OS permission on the phone, and the app's registration. A rule with Push on and permission denied fails silently, and nothing in IoTFlows shows the message was never delivered.

1. Confirm the recipient is on that event type's Push list.
2. Confirm notifications are allowed for IoTFlows in the phone's own settings.
3. Confirm they are signed into the organization the machine belongs to. Push routes per organization.

Push stops arriving after an Android user signs out and back in. This is a known defect: the app does not unregister its push token on sign-out, and the new session never gets one. Sign out, delete the app, reinstall it and sign in again. See Turn on push notifications on your phone.

SMS never arrived

SMS reaches a member only if their account carries a verified phone number. A member without one is listed as No phone number, cannot be added to the list, and clicking them reports This user has not added their phone number. A member who has opted out of texts is listed as Opted Out and stays unreachable until they opt back in. See Change your phone number.

Check the list before you check the carrier. A member who changed their number and did not update their profile is subscribed to an old handset.

The Slack, Teams or Discord message never posted

Work from the integration rather than from the rule. Open /integrations and click Test integration on the destination.

• Test event sent, and the message appears in the channel. The integration is fine, so the fault is upstream: the Integrations cell on that event row, or the event never firing.
• Test event sent, and nothing appears in the channel. The webhook was revoked or the channel was deleted at the platform end. Create a new webhook there and paste the new URL into the integration.
• Failed to send test event. IoTFlows could not reach the URL. Re-copy it from the platform, and check the integration is enabled.

An integration tagged Disabled is still listed everywhere, including in the per-event dropdown, and sends nothing until it is enabled again. See Send alerts to Slack, Teams, or Discord.

The rule fired too often

Too many alerts and no alerts have the same ending, which is a rule nobody reads. Four causes, in the order they are worth checking.

• The threshold is below normal operation. A 5-minute Machine Down on a machine that changes over in 12 alerts on every changeover. Set it above the longest pause that is part of the job.
• Both Machine Down rows are on for the same channel. The warning and critical rows are separate rules watching the same stop, so a long stop alerts twice. Keep the critical row on a narrower channel, for example SMS for the maintenance lead only.
• Device Offline is set too short. Ten minutes is the default for a reason. Two minutes on a machine at the edge of an access point's range turns one flaky afternoon into forty alerts, see Troubleshoot a device that is offline.
• The shock threshold matches the machine's normal stroke. A press reporting 3 g every cycle is not faulting. Raise the threshold rather than turning the rule off, see Shock events.

Rules do not know about shifts or the plant calendar. A machine nobody runs at night still alerts at night, so disable Machine Down on machines that are idle by design.

The rule fired for the wrong machine

Rules are stored on the machine, not on the sensor. Two consequences when hardware moves.

• A sensor moved to another machine reports against that machine's rules and subscriber lists, not the ones you set up for it before the move.
• The shock threshold is the exception. It is written to the device itself, so it travels with the sensor and applies to whatever machine it is now reading.

If the alert names a machine you did not expect, open that machine's Event Notifications and read its rules. Two machines with similar names is the other common cause, and renaming one is faster than explaining it, see Edit a machine.

The event type is not in the list

The modal hides the sections the device cannot produce, so this is a device answer rather than a permission answer. A BeamTracker shows machine status and connectivity only, and a SenseAi on firmware below 5 keeps shock but loses health and temperature.

The full table is at Which sections you see for which device.

Check the device before you check anything else. It is the reason more often than a role is, and no setting on the page will add the section back. Ask IoTFlows to update a device on old firmware, see Get support.

Errors

A generic Something went wrong or An error occurred means the request failed and the change was not saved. Reopen the modal to see the values that actually stuck, then retry.

See also

• Set alert rules for a machine
• Event types and channels
• Turn on push notifications on your phone
• Send alerts to Slack, Teams, or Discord
• Review and dismiss machine events