What an Alarm Actually Tells You About Timing

Why this matters

Two techs read the same alarm log and reach opposite conclusions about which fault came first, and the one who reads it literally is usually wrong. An alarm timestamp records the moment a condition satisfied a detection rule. It does not record the moment the condition began, and the gap between those two moments is different for every alarm on the list. Chase the first line in the log and you can spend a full visit on the consequence while the cause sits three lines down.

This card is about the timing information an alarm carries and, more usefully, the timing information it deliberately does not carry. Siblings cover what a sensor's number means and how to read a sequence of operation as a diagnostic; those are cited at the end rather than repeated here.

Four gates sit between the condition and the line in the log

Every alarm passes all four, and each one adds delay that belongs to that alarm alone.

1. The threshold. A comparison against a value, sometimes with its own deadband so the alarm does not chatter at the edge. The unit of analysis is the input the comparison reads, which is not always the input on the screen.
2. The sample. The controller only evaluates the comparison when it scans that point. A point scanned every 5 seconds can be over threshold for 4.9 seconds and evaluate as normal.
3. The delay. An on-delay requires the condition to persist for a stated time before the alarm is declared. This is the largest and most variable of the four, and it is set per alarm, not per controller.
4. The declaration and publish. The alarm is latched, annunciated locally, and then made available to whatever is logging it. If a front end polls the controller on an interval, the log's timestamp may be the poll's, not the controller's.

Only gate 1 has any contact with the process. Gates 2 through 4 are bookkeeping performed after the fact, and they are where the timestamp comes from.

The four things an alarm timestamp is not

It is not the onset of the condition. It is onset plus that alarm's own sample and delay. Two alarms with different delays, from conditions that began in one order, will routinely log in the other order.

It is not evidence the condition still exists. A latched alarm holds until something clears it. An alarm sitting active on a screen tells you a condition was true at some point after the last reset. Whether it is true now is a separate measurement.

It is not a causal ordering. Alarm sequence and cause sequence are different lists. The only alarm that carries a causal claim is one the controller explicitly labels first-out, meaning it was captured by logic designed to freeze the first trip of a group, and that logic has its own scan resolution which you should find before you trust it.

It is not a common clock. Where a controller, a front end and a separate protective device each stamp their own events, three clocks are in play, and drift between independent clocks is normal and unannounced. Before comparing timestamps across devices, compare the devices' current time displays to each other.

Why alarm order is mostly a report on delay settings

Take two conditions that begin 15 seconds apart. The earlier one is watched by an alarm with a 30 second on-delay because it is prone to nuisance trips. The later one is watched by an alarm with a 2 second delay because it is a fast fault. The log shows the later condition first, by 13 seconds, and it will do that every single time this pair occurs.

That is not a defect. The delays were set for good reasons. But it means the log ranks alarms by how tolerant each one is, and a reader who takes the top line as the origin has read the tuning table, not the fault.

The correction is arithmetic you can do at the panel: for each alarm, subtract its own on-delay and its own sample interval from its logged time. What you get is not a moment, it is a window, and the width of the window is the sample interval. Compare windows, not points. Where two windows do not overlap, you have a real ordering. Where they overlap, you do not, and saying so is a finding.

The restore has its own rules, and they are not the alarm's

Return-to-normal is gated separately. It usually carries its own off-delay, often longer than the on-delay so the alarm does not flicker, and on a latched alarm it may not clear at all without an operator action.

This produces a specific misreading: a technician makes a change, watches the alarm stay up for a minute, and concludes the change did nothing. The condition may have cleared in 3 seconds and the annunciation may be serving a 60 second off-delay. Before judging a repair by the alarm, find the off-delay, or judge it by the measured quantity instead.

What a communications gap or a power restoration does to the timeline

Where a controller buffers events and uploads them after a gap, the log receives a burst of entries with the same arrival time and different internal times. Some systems preserve the internal times, some stamp everything with the arrival, and a few do both in different columns that look identical at a glance.

After a power interruption the problem is worse: an unpowered controller does not evaluate anything, so conditions that existed through the outage generate no events at all, and the first entries after restoration are the startup sequence's own alarms. A blank stretch in a log is not evidence of a quiet period. Establish whether the device was powered and communicating across the window before you read the absence of alarms as information.

Worked example: three alarms, and the log's first line was the second event

A packaged unit shuts down. The front end shows three alarms, and the on-site controller's alarm parameters are read from its own configuration screens. All times are from the site's front end unless stated.

Read literally, the order is B, then A, then C, and the obvious story is that something overheated, which then killed airflow, which then faulted the unit. That story is wrong in its first move.

Correct each entry back to an onset window by subtracting the delay and then the sample interval.

• B: 10:14:22 minus 2 seconds of delay is 10:14:20. Minus up to 1 second of sample gives an onset window of 10:14:19 to 10:14:20.
• A: 10:14:35 minus 30 seconds of delay is 10:14:05. Minus up to 5 seconds of sample gives an onset window of 10:14:00 to 10:14:05.
• C: the timestamp is made at the front end on a 60 second poll, so the only honest statement is that the condition became true somewhere in the 60 seconds ending 10:15:00. The window is 10:14:00 to 10:15:00.

A's window closes at 10:14:05. B's window opens at 10:14:19. They do not overlap, so A genuinely preceded B by at least 14 seconds and possibly 20. The log's first line was the second event. C's window spans both, so C cannot be ordered against either, and the correct thing to write in the ticket is that C is unordered rather than last.

The 14 second floor comes from the closest edges of the two windows, 10:14:05 and 10:14:19, and the 20 second ceiling from the furthest, 10:14:00 and 10:14:20. Both are floors and ceilings on the gap, not the gap.

What this changes. The airflow condition led. That reorders the whole visit: discharge temperature rising behind a collapsing airflow is expected physics, so the temperature alarm is a consequence and the time spent on it is time wasted. Had the delays run the other way around, with a 30 second delay on the temperature and 2 seconds on airflow, the raw log would have read A, B and been correct by accident, which is exactly why the accidental case teaches nothing.

The failure mode. A tech who works the top line replaces or recalibrates something on the temperature side, sees the unit run on a mild afternoon, and calls it fixed. The airflow restriction is still there. It returns on the first hot day, on someone else's ticket, and the second tech now has a repair history pointing at the wrong subsystem.

When the alarm came from a protective device

Alarm C in the example is a latched unit fault, which on most equipment means a protective device opened and the controller reported it. A protective device is not a control, and the distinction decides your next move.

Establish why it opened before you treat it as the fault. A limit, a pressure switch or an interlock that opens on a genuine excursion has done its job, and the excursion is your work. Replacing a device that operated correctly puts you at the same end state as jumpering it, one step slower and with a part on the invoice. The evidence you need is a measurement of the quantity the device watches, taken while the machine runs, against the device's stated trip point.

Getting that measurement usually means an open enclosure. De-energize the line-voltage side, lock and tag it, and verify dead before your hands go in; for a panel or branch circuit the controlling standard is 29 CFR 1910.333(b)(2), and the live-dead-live proving sequence is NFPA 70E-2021, 120.5. If the reading genuinely cannot be taken dead, that is the narrow troubleshooting allowance at 29 CFR 1910.333(a)(1), and it comes in the same breath as meter and leads rated for the circuit's measurement category and available fault current plus the shock and arc-flash protection the assessment calls for. Where the same visit requires reaching past a spring-loaded linkage, a pressurized vessel or an accumulator, that stored energy is isolated and relieved under 29 CFR 1910.147 before any part of you is inside the swing path.

How to verify you read the timing correctly

Read the delay and sample values off the running controller, not off the submittal. Alarm parameters are edited in the field more often than any other setting, and the as-built rarely follows.

Compare the clocks before you compare the events. Note each device's displayed time to the second in your ticket. A 40 second offset between a controller and a front end will manufacture a causal story out of nothing, and it is invisible unless you look for it.

State every corrected time as a window with its width. If your note says onset 10:14:05, the next reader treats it as measured. If it says onset between 10:14:00 and 10:14:05, five second sample interval, the next reader can extend your work.

Confirm the ordering claim would survive the widest window. Re-run your comparison using the largest sample interval in the group applied to every alarm. If the ordering holds, it is robust. If it collapses, you have a hypothesis, not a finding, and the ticket should say so.

References

• 29 CFR 1910.333(a)(1) - live parts de-energized before work, and the narrow conditions permitting energized troubleshooting
• 29 CFR 1910.333(b)(2) - lockout and tagging for work on electric circuits and equipment
• 29 CFR 1910.147 - control of hazardous energy for mechanical isolation and stored energy
• NFPA 70E-2021, 120.5 - process for establishing and verifying an electrically safe work condition
• See related: The Sequence of Operation as a Diagnostic Instrument; What a Sensor Actually Reports; How to Tell a Reset State From a Real Fault After a Power Interruption