Where your alarm history actually lives

The default is memory

By default, current alarm data is only stored in memory, and a finite number of events is retained for each alarm. That number is the Live Event Limit, which caps live — active or unacknowledged — events per alarm and defaults to 5, and Inductive Automation notes plainly that it does not store history for those events. It is easy to assume alarms are being recorded somewhere simply because they appeared on a screen.

Storing them properly is a deliberate act: you configure an Alarm Journal Profile, and from then on Ignition records what happened. Without one, the alarm status table works, notifications work, and the alarm history you would need afterwards is not being kept. An Alarm Notification Profile pointed at an Audit Profile does record notification attempts and acknowledgements separately, but that is a different record and also not on by default.

What it keeps, and where

A journal stores basic data about alarms that have occurred — source and timestamp, associated data, and the values of the alarm’s properties at the time the event occurred. That last part matters more than it sounds. It is the difference between knowing an alarm fired and knowing what the setpoint was when it did.

There are three places it can go, and the choice has consequences:

• In a database, using an existing gateway database connection. The usual arrangement, and the one that behaves like the rest of your historical data.
• Remotely, using another Ignition gateway’s alarm journal profile. Useful for a fleet with a central gateway — with one caveat below.
• Internally, storing alarm information into the Ignition install directory. Convenient, and the option that needs the most care.

The setting that fills a disk

Data pruning is not on by default. Enable Data Pruning defaults to false; when you do enable it, Prune Age defaults to 1 and Prune Age Units to years.

Inductive Automation is direct about the consequence: it strongly encourages setting a data pruning value for internal alarm journal profiles, to avoid running out of hard drive space. An internal journal with pruning off has no upper bound and lives on the gateway’s own disk, which is the same disk everything else on that gateway needs.

This is worth checking today rather than at some point. It is one checkbox, it defaults to the unbounded option, and for an internal profile the consequence Inductive Automation names is running out of hard drive space on the gateway, which tends to surface as problems that look nothing like alarms.

Decide what you are storing before you store everything

A journal can record active, clear and acknowledged events, and separately whether an alarm was enabled or disabled. There are toggles for storing shelved events and for storing enabled and disabled events.

Filtering is where the volume decision gets made, and there is a documented trap in it. The three filter properties — Filter by Alarm Source, Filter by Display Path, and Filter by Display Path or Source — combine with logical AND, so an alarm must satisfy every one you populate. Inductive Automation recommends against using all three on the same journal. Minimum priority runs Diagnostic, Low, Medium, High, Critical, and defaults to Low, which means Diagnostic events are excluded unless you lower it.

The useful question is what you will actually be asked. “What alarmed during the shift” needs active and clear. “Who acknowledged it and when” needs acknowledged events. “Why did nobody get notified” needs shelved and disabled events, and Store Shelved Events is not enabled by default. If you are going to be asked why an alarm did not reach anybody, the answer often lies outside the alarm event itself: shelved and disabled events show suppression, while notification attempts and failed attempts are recorded only if the Alarm Notification Profile is pointed at an Audit Profile — though Inductive Automation notes the audit system cannot report failures that occur outside the gateway, such as an error downstream in a VOIP system.

Two things it inherits from elsewhere

Store and forward applies to database and remote profiles, not to all three. Database profiles carry a Use Store and Forward setting that is enabled by default, and remote profiles have their own defaulting to true. Inductive Automation documents no store-and-forward path for internal profiles, which makes sense — an internal journal writes locally and has no database delivery to buffer.

So for a database-backed journal, it behaves during an outage the way a SQL Historian does, with the same buffering and the same limits — we covered those in what happens when the database goes away. Note the comparison holds only for database-backed historians: 8.3’s Core Historian does not use store and forward at all.

And if you are using a remote journal across gateway versions, note the serialization constraint: 8.3 gateways cannot store alarm journal data to a remote 8.1 gateway. Inductive Automation states the order: upgrade the central server hosting the data to 8.3 first, before any remote 8.1 gateways. That is the same constraint as Edge sync, which we covered in Ignition Edge at a remote site.

Worth checking

• Is there an alarm journal profile at all, or is alarm data memory-only?
• If it is an internal profile, is data pruning enabled — and what is the prune age?
• Are shelved, enabled and disabled events being stored, or only active and clear?
• Does the minimum priority filter exclude something you would later want to explain?
• If the journal is remote, are the gateway versions compatible in the direction data flows?

Common questions

References

• Inductive Automation — Alarm Journal
• Inductive Automation — Alarming
• Inductive Automation — Configuring Alarms
• Inductive Automation — Gateway General Alarm Properties: Live Event Limit
• Inductive Automation — Store and Forward
• Inductive Automation — Tag History Providers: Core Historian and store and forward
• Inductive Automation — Alarm Notification Auditing
• Inductive Automation — Auditing Actions Reference: notification attempts and failures