# Tag alarms sometimes reverting to default

**URL:** <https://forum.inductiveautomation.com/t/tag-alarms-sometimes-reverting-to-default/34246>\
**Category:** Ignition\
**Tags:** ignition80\
**Created:** [April 27, 2020, 6:13pm UTC](https://forum.inductiveautomation.com/t/tag-alarms-sometimes-reverting-to-default/34246 "2020-04-27T18:13:21Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![richard.d.white](https://avatars.discourse-cdn.com/v4/letter/r/b2d939/32.png) [@richard.d.white](https://forum.inductiveautomation.com/u/richard.d.white)\
**Post date:** [April 27, 2020, 6:13pm UTC](https://forum.inductiveautomation.com/t/tag-alarms-sometimes-reverting-to-default/34246/1 "2020-04-27T18:13:21Z")

</div>

Many of our field devices are monitored via Ignition using UDT’s - The UDT is the same for all of these. When a tag alarm is triggered, usually the message that is emailed is correct - the configured alarm for that tag has a custom message and custom subject. However, sometimes I’ll receive a block of email alarms that are generic; ie message will be something like: “At 01:11:01, alarm “High Pressure Alarm” at “” transitioned to Active.”

The configured expressions for the alarms are as follows:  
subject: {Gateway}+" “+{label}+” Irrigation Controller HIGH Pressure Alarm"  
message: round({[.]Calculated pressure},1)+"PSI measured on “+{label}+ " drip line header. Risk of line blow-out. Please check!”

Is it possible that something is going on with {Gateway} or {label}? has anyone seen anything similar to this?

Thanks!

---

<div class="post-metadata">

**Author:** ![richard.d.white](https://avatars.discourse-cdn.com/v4/letter/r/b2d939/32.png) [@richard.d.white](https://forum.inductiveautomation.com/u/richard.d.white)\
**Post date:** [May 4, 2020, 5:58pm UTC](https://forum.inductiveautomation.com/t/tag-alarms-sometimes-reverting-to-default/34246/2 "2020-05-04T17:58:30Z")

</div>

Just an update in case anyone is having a similar issue:

I found that the {label} tag was not populated completely as I had thought for every UDT. Changing this to {InstanceName} resolved the issue!
