# Indirect Bindings with Alarm Metrics **URL:** \ **Category:** Ignition\ **Tags:** ignition83\ **Created:** [May 20, 2026, 4:09pm UTC](https://forum.inductiveautomation.com/t/indirect-bindings-with-alarm-metrics/115624 "2026-05-20T16:09:47Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![jrusso](https://avatars.discourse-cdn.com/v4/letter/j/c0e974/32.png) [@jrusso](https://forum.inductiveautomation.com/u/jrusso)\ **Post date:** [May 20, 2026, 4:09pm UTC](https://forum.inductiveautomation.com/t/indirect-bindings-with-alarm-metrics/115624/1 "2026-05-20T16:09:47Z")
Good Morning all, I've recently upgraded to 8.3 on a large customer of mine, who I was previously using gateway scripts and expression tags to make my own "Alarm Metrics" before that feature was added. I'm considering shifting over to this new feature, but I have concerns regarding its subscription method. It is my understanding that the alarm metrics are not constantly being updated unless something is explicitly subscribed to them, which makes sense from a performance standpoint. My question is, does using indirect bindings reliably update the alarm metrics since nothing is directly subscribed? My current method is a UDT with several different expression tags that look like this: ```python runScript("gs.SystemAlarmsQtyWarn", 900000, {[.]SystemPath}) ``` I have hundreds of 'areas' that use this UDT, so having to only change the tag path is essential for me. My problem with alarm metrics is that if I am not able to use indirect tagging, it would be a massive undertaking to have to directly bind each of these. Does anyone have any insight on how Alarm Metrics work with indirect tagging and their reliability at scale? Thanks ---
**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:** [May 20, 2026, 4:13pm UTC](https://forum.inductiveautomation.com/t/indirect-bindings-with-alarm-metrics/115624/2 "2026-05-20T16:13:18Z")
An indirect binding is still a binding. It's just automagically changeable. I've been very happy with the new Alarm Metrics. ---
**Author:** ![jrusso](https://avatars.discourse-cdn.com/v4/letter/j/c0e974/32.png) [@jrusso](https://forum.inductiveautomation.com/u/jrusso)\ **Post date:** [May 20, 2026, 4:42pm UTC](https://forum.inductiveautomation.com/t/indirect-bindings-with-alarm-metrics/115624/3 "2026-05-20T16:42:22Z")
Alright, that's what I would assume, but I could've sworn I had read something about inconsistencies with the indirect bindings early on in 8.3. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [May 20, 2026, 4:56pm UTC](https://forum.inductiveautomation.com/t/indirect-bindings-with-alarm-metrics/115624/4 "2026-05-20T16:56:42Z")
Scripted reads are not the same as actual indirect tag bindings. Your `runScript()` expression is not a tag binding. ---
**Author:** ![jrusso](https://avatars.discourse-cdn.com/v4/letter/j/c0e974/32.png) [@jrusso](https://forum.inductiveautomation.com/u/jrusso)\ **Post date:** [May 20, 2026, 5:52pm UTC](https://forum.inductiveautomation.com/t/indirect-bindings-with-alarm-metrics/115624/5 "2026-05-20T17:52:30Z")
I understand that, the runScript() expression is what I'm trying to replace with the Alarm Metrics. Essentially instead of running different scripts to query alarm counts I would have an tag binding like ```python tag({[.]SystemPath} + "/Alarm Metrics/activeUnackCount") ``` My question is whether or not that would be reliable with the subscription model, and how that would scale to 500+ tags ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [May 20, 2026, 6:35pm UTC](https://forum.inductiveautomation.com/t/indirect-bindings-with-alarm-metrics/115624/6 "2026-05-20T18:35:03Z")
For an expression tag, that looks fine, and should work well. (Do remember that `tag()` is a disaster in UI bindings. Use a proper indirect tag binding there.) ---
**Author:** ![jrusso](https://avatars.discourse-cdn.com/v4/letter/j/c0e974/32.png) [@jrusso](https://forum.inductiveautomation.com/u/jrusso)\ **Post date:** [May 20, 2026, 6:55pm UTC](https://forum.inductiveautomation.com/t/indirect-bindings-with-alarm-metrics/115624/7 "2026-05-20T18:55:29Z")
Great, appreciate the input. And yes this binding is not for UI, it would be on an expression tag that is used with other memory tags to determine a "state". Do you have any opinions on the Alarm Metrics gateway load? The one thing I like about my current script approach is that I'm able to control the polling rate directly.Like I said I will have a lot of these tags pointing to alarm metrics if I end up going down this path ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [May 20, 2026, 7:05pm UTC](https://forum.inductiveautomation.com/t/indirect-bindings-with-alarm-metrics/115624/8 "2026-05-20T19:05:28Z")
> [@jrusso](#): > > any opinions on the Alarm Metrics gateway load Not enough experience with it to say. ---
**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:** [May 21, 2026, 12:47pm UTC](https://forum.inductiveautomation.com/t/indirect-bindings-with-alarm-metrics/115624/9 "2026-05-21T12:47:02Z")
Not seeing an issue with load. We've got a system we're getting cleaned up that has about 40k tags, and about 1000 alarms at any given moment with alarms constantly clearing and going active. (it's an inherited disaster for the customer - we're helping them clean things up)