# 8.3.10 UDT disabling triggering alarm... odd one

**URL:** <https://forum.inductiveautomation.com/t/8-3-10-udt-disabling-triggering-alarm-odd-one/117487>\
**Category:** Ignition\
**Tags:** ignition83\
**Created:** [October 14, 2026, 9:24pm UTC](https://forum.inductiveautomation.com/t/8-3-10-udt-disabling-triggering-alarm-odd-one/117487 "2026-10-14T21:24:12Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![tgarrison](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/tgarrison/32/80965_2.png) [@tgarrison](https://forum.inductiveautomation.com/u/tgarrison)\
**Post date:** [October 14, 2026, 9:24pm UTC](https://forum.inductiveautomation.com/t/8-3-10-udt-disabling-triggering-alarm-odd-one/117487/1 "2026-10-14T21:24:12Z")

</div>

So working on a 8.3.10 system, with about 116k tags in one provider (so far - it's going to increase a bunch more).  
Loaded about 800 udt instances today for AIs that have alarm udts as childern.

Alarm UDTs have a "stat" tag that handles the actual alarm. And an "ALMEN" tag that handles enable/disable (referenced by the actual alarm config). The alarm config's enable is an expression: if(isGood({[.]ALMEN}),{[.]ALMEN},True).

All the UDT instances have the ALMEN = false

So I went and disabled some of the UDTs, and AFTER I disable them, I'm getting an alarm (on some of the tags, not all. And only generally on 1 of the alarms. So then I have to re-enable the UDT, acknowledge the alarm (which throws an error saying it's trying to ack an alarm that is no longer active). If I then go and disable the UDT again, the alarm pops back up. Rinse-and-repeat.

UNLESS - after acking the false alarm, I disable the STAT tag first and apply.. THEN disable the UDT. Then I don't get an alarm.

To me, it seems like while disabling the entire UDT, the ALMEN tag is getting disabled before the STAT, and the STAT is then interpreting the disabled ALMEN as "bad", so enabling the alarm.

Annoying as can be since I just disabled a few hundred UDTs and now have to go renable individually to clean up the mess.

---

<div class="post-metadata">

**Author:** ![michael.flagler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/michael.flagler/32/26272_2.png) [@michael.flagler](https://forum.inductiveautomation.com/u/michael.flagler)\
**Post date:** [October 14, 2026, 9:41pm UTC](https://forum.inductiveautomation.com/t/8-3-10-udt-disabling-triggering-alarm-odd-one/117487/2 "2026-10-14T21:41:47Z")

</div>

What if you add an extra condition to your expression to check the quality of the STAT tag also? This way if there is a race condition, maybe that will catch it.

---

<div class="post-metadata">

**Author:** ![tgarrison](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/tgarrison/32/80965_2.png) [@tgarrison](https://forum.inductiveautomation.com/u/tgarrison)\
**Post date:** [October 14, 2026, 9:56pm UTC](https://forum.inductiveautomation.com/t/8-3-10-udt-disabling-triggering-alarm-odd-one/117487/3 "2026-10-14T21:56:17Z")

</div>

Maybe. It's just weird and I've never seen it before. I'm wondering if it's got anything to do with the fixes they put in place to resolve the regressions on the alarm Querystatus stuff. Because what's really odd-- the alarm shows as Active in the Status Table, even though it's not. Even the Alarm Metrics rollup doesn't show any active alarms.