# Realtime alarms without polling/looping vs event based alarms

**URL:** <https://forum.inductiveautomation.com/t/realtime-alarms-without-polling-looping-vs-event-based-alarms/52316>\
**Category:** Ignition\
**Tags:** ignition80, database, scripting, perspective\
**Created:** [October 25, 2021, 9:19pm UTC](https://forum.inductiveautomation.com/t/realtime-alarms-without-polling-looping-vs-event-based-alarms/52316 "2021-10-25T21:19:28Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![r.p](https://avatars.discourse-cdn.com/v4/letter/r/71e660/32.png) [@r.p](https://forum.inductiveautomation.com/u/r.p)\
**Post date:** [October 25, 2021, 9:19pm UTC](https://forum.inductiveautomation.com/t/realtime-alarms-without-polling-looping-vs-event-based-alarms/52316/1 "2021-10-25T21:19:28Z")

</div>

Hello,  
currently there are essentially two methods, that I know of, to retrieve active alarms:

querying the db, i.e.: " SELECT \* FROM alarm\_events" with a fixed polling time

looping with a python script, i.e. " system.alarm.queryStatus()" and then sleeping in between or similar.

both of these methods are looping/polling methods and they are quite expensive (we use the db polling at the moment with a 5 minutes delay and we are quickly reaching millions of queries per hour on each of our Aurora RDS cluster).

Is there some event based / subscription method for fetching alarms which is less taxing and more realtime? something like system.alarm.subscribe(tag\_path) which fires when an alarm is ever raised or reenters?

Thank you

---

<div class="post-metadata">

**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:** [October 25, 2021, 9:42pm UTC](https://forum.inductiveautomation.com/t/realtime-alarms-without-polling-looping-vs-event-based-alarms/52316/2 "2021-10-25T21:42:17Z")

</div>

You can call scripts from alarm pipelines and cache the information.

---

<div class="post-metadata">

**Author:** ![r.p](https://avatars.discourse-cdn.com/v4/letter/r/71e660/32.png) [@r.p](https://forum.inductiveautomation.com/u/r.p)\
**Post date:** [October 25, 2021, 10:33pm UTC](https://forum.inductiveautomation.com/t/realtime-alarms-without-polling-looping-vs-event-based-alarms/52316/3 "2021-10-25T22:33:08Z")

</div>

We are experimenting with something similar however the solution is not very robust:

- we need to define a pipeline for all alarms
- we need to define the pipeline for the raise, acked and entered states
- we must store a last-executed time in a memory tag to avoid consecutive alarms from trashing the server.
- we must create a polling gateway event to execute all this logic every 1 minute.

I hoped perspective / ignition offered something more realtime and event oriented.

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [October 25, 2021, 11:03pm UTC](https://forum.inductiveautomation.com/t/realtime-alarms-without-polling-looping-vs-event-based-alarms/52316/4 "2021-10-25T23:03:35Z")

</div>

Not from inside the Ignition runtime, but it’s possible using the module SDK to register a listener that receives active, clear, and acknowledge notification for events as they occur.

---

<div class="post-metadata">

**Author:** ![r.p](https://avatars.discourse-cdn.com/v4/letter/r/71e660/32.png) [@r.p](https://forum.inductiveautomation.com/u/r.p)\
**Post date:** [October 27, 2021, 9:00pm UTC](https://forum.inductiveautomation.com/t/realtime-alarms-without-polling-looping-vs-event-based-alarms/52316/5 "2021-10-27T21:00:00Z")

</div>

Thank you for the response. I’ll take a look at the SDK.