The interval between the alarm and the dispatch belongs to nobody
It looks like dead time on an incident timeline. It is the part of the outage where all the judgement happens, and no system owns it.
By Jeel Patel — Co-founder, FieldCamp · CEO, Upper Route Planner
Fifty alarms arrive from one failing unit. Somebody reads them, works out which are the same event, decides whether it matters tonight, establishes who is allowed to touch the equipment, and makes a phone call.
That stretch of minutes has no owner, no metric and no record. It is the part of a cooling outage no system was designed to hold, and usually the part nobody can account for afterwards. Most sites can quote a response-time SLA to the minute and cannot say how long this took.
- The alarm-to-dispatch interval is the time between the first related alarm and the right person being sent.
- Five judgements are made inside it, each needing information from a different system.
- No single system holds both timestamps, which is why almost nobody measures it.
- You can measure it this week from the BMS event log and the dispatch log, with no new software.
What is the alarm-to-dispatch interval?
The alarm-to-dispatch interval is the elapsed time between the first alarm belonging to an incident and the moment a qualified person is actually sent to it. It starts at the earliest related event in the building management system, not at the one somebody happened to notice. It ends at dispatch, not at ticket creation — a work order can sit unassigned for an hour.
It is a different quantity from the two metrics facilities teams already report, and the vocabulary for it is borrowed from IT incident practice. Response time usually starts when a ticket is raised, which is after the judgement has been made. Mean time to repair starts later still. The interval sits in front of both, and it is invisible to both.
It is a different quantity again from mean time to acknowledge, which IT incident practice does track. Acknowledgement means a human has seen it; dispatch means a qualified human is on the way, and in a critical facility those can be an hour apart.
| Time | What the record shows |
|---|---|
| 03:14 | Supply-air sensor on CRAH-07 crosses its limit |
| 03:16 | BMS has raised 51 events across the unit, the shared chilled-water loop and four racks |
| 03:41 | First work order created |
| 03:58 | Technician dispatched |
Every system in the building watched that happen, and none of them owns it. The interval between the first signal and the right person being on the way is unowned, unmeasured, and routinely a large part of the outage.
What happens during the alarm-to-dispatch interval?
On an incident timeline it reads as dead time. It is not.
Five judgements are made inside it, in sequence, usually by one person, usually from memory. Each needs information held in a different system, and none of those systems is asked to produce it in a hurry.
| The judgement | What it needs | Where that lives |
|---|---|---|
| These signals are one physical event | Which unit feeds which row, which loop they share | DCIM, and the head of whoever commissioned the hall |
| It has this much margin before load is at risk | Current load, inlet temperatures, ride-through time | BMS trends, plus arithmetic nobody has automated |
| This procedure applies | The approved MOP, SOP or EOP for this intervention | A document store, or no document at all out of hours |
| These people may perform it | Competence, OEM authorisation, site clearance, shift | Three separate lists, none of them joined |
| This is worth waking someone for | All four of the above, weighed together | Nowhere |
The join is made in somebody's head, at three in the morning, against a clock. That is not a training problem — the inputs genuinely are scattered, and nobody has ever been asked to hold them together under time pressure.
Where do the minutes actually go?
The interval is not one delay. It is four, and they compound.
| Stage | What is happening | What makes it longer |
|---|---|---|
| Notice | The alarm reaches a human who is looking | Alarm flood — ISA-18.2 treats a rate beyond what one operator can manage as a distinct failure condition, not a busy period |
| Separate | Deciding which alarms are one event | No topology model, so eleven alarms read as eleven problems |
| Rank | Deciding whether it is tonight's problem | No margin figure, so severity is guessed from the alarm text |
| Reach | Finding someone qualified, authorised and awake | Rosters, warranty terms and clearance held in three places |
Shift handover multiplies all four. So does unfamiliar equipment, which is why a hall commissioned by a contractor who has since left is measurably worse.
Mean time to acknowledge is a metric most critical facilities can produce for IT incidents and not for cooling ones.
Why does no system own this interval?
| System | What it holds | Where it stops |
|---|---|---|
| BMS | Points that crossed limits, with timestamps | No model of which unit feeds which row |
| DCIM | The facility, the racks, the cooling chain | Not watching the alarm stream for meaning |
| CMMS | Assets, contracts, work history | Receives a decision somebody already made |
| Alarm routing and on-call | Delivery, escalation, acknowledgement | Does not decide whether it deserved one |
None of these is failing. Each does the job it was designed for.
The interval sits in the space between their designs, which is why adding another one of them does not close it. A fifth system with the same shape produces a fifth partial view, and one more console for the shift engineer to check.
Why doesn’t faster notification fix it?
The obvious move is to shorten the interval by delivering alarms faster: routing rules, escalation trees, acknowledgement timers. That is a real improvement, and it solves a different problem.
Automating the handoff between two systems that were never designed to reason does not produce reasoning. It produces faster paperwork.
Fifty alarms delivered in nine seconds instead of four minutes are still fifty alarms, and the person receiving them still has to make the five judgements. Speed of delivery is not ownership of the decision.
How to measure your own interval this week
No new software is required to put a number on this. The two timestamps already exist in systems you own.
- Pick three unplanned cooling incidents from the last quarter — not the worst ones, ordinary ones.
- In the BMS event log, find the first alarm that belonged to each incident. Not the first one anyone acted on; the first one that fired.
- In the CMMS or the call log, find the moment a person was actually dispatched — not when the ticket was raised, which is often later.
- The distance between the two is the interval. Record it alongside the total outage duration.
- Repeat for a shift-handover incident and a weekend incident, which is where the distribution has its tail.
Most sites have never produced this number, because no single system holds both timestamps. The BMS has the first and the CMMS has the second, and joining them is a spreadsheet exercise nobody has been asked to do.
The ratio is the useful part. An interval that is a third of total outage duration is a different problem from one that is a twentieth, and the two call for opposite responses.
What to record for each incident
Five fields are enough, and they all come from logs you already keep. Put them in a spreadsheet rather than a tool — the point is the distribution, and three rows will already tell you something.
| Field | Where it comes from | Why it matters |
|---|---|---|
| First related alarm | BMS event log, earliest event of the incident | The real start. Not the first one anyone acknowledged. |
| Dispatch | Call log, or the work order's assignment timestamp | The real end. Ticket creation is usually earlier and misleading. |
| Total outage | Incident record | Gives you the ratio, which is more useful than the raw minutes. |
| Shift state | Rota | Handover and weekend incidents are where the tail lives. |
| Margin at the start | Load and inlet temperatures at the first alarm | Forty minutes with hours of margin is fine. Four minutes at 95% capacity is not. |
Three mistakes that make the number wrong
The first is starting the clock at the acknowledged alarm rather than the earliest related one, which quietly hides the part you are trying to see. The second is ending it at ticket creation, which can precede dispatch by an hour on a busy night. The third is averaging across incident types — a planned-maintenance callout and a 03:00 CRAH failure are not the same population, and mixing them produces a mean that describes neither.
Take the median rather than the mean, and look at the worst case separately. The tail is where the outage risk actually sits, and an average hides it by design.
The number is also the cheapest argument available to a facilities leader asking for anything. It converts an instinct that nights are chaotic into a figure with two timestamps behind it.
| What the ratio shows | What it means | What to do about it |
|---|---|---|
| Interval is a small fraction of the outage | The judgement is fast; the repair is slow | Look at parts, access and authorisation, not at detection |
| Interval is a third or more of the outage | The judgement is the outage | Instrument the five judgements before buying anything |
| Interval varies wildly between incidents | It depends who was on shift | The knowledge is in people, not in a system |
Two caveats on the number itself. Three incidents is a sample rather than a distribution, so treat the first pass as a direction and keep adding rows as incidents happen. And the interval is not a performance measure for whoever was on shift — it measures how much the systems left them to do alone, which is a different question and a fairer one.
How to shorten the interval without new software
Three of the four delays respond to organisational change alone, and they are worth attempting before evaluating any tooling. The fourth is the one that genuinely needs a system.
- Write down the topology. A single sheet naming which CRAH feeds which row, which units share a loop, and what redundancy each hall carries removes most of the separating work. It goes stale, which is an argument for maintaining it rather than for skipping it.
- Publish the margin. If the shift engineer can see minutes-to-envelope rather than a temperature, ranking stops being a guess. Many BMS installations can compute this and simply have not been asked to.
- Join the three qualification lists. Competence, OEM authorisation and site clearance usually live in three places owned by three people. One table, reviewed monthly, converts a phone-around into a lookup.
- Rationalise the alarms. Fewer, better-justified alarms shorten the notice and separate stages directly, which is the subject of the ISA-18.2 guide.
What none of that fixes is the correlation itself. Deciding that fifty-one events are one physical incident, against live topology and remaining margin, is the part that stays manual until something computes it.
What would it take to own the interval?
Not a faster pipe. A layer that holds the topology, reads live state, and produces one artefact: a decision record.
Coolant flow restriction upstream of CDU-2E
- Observed
- CDU-2E Δp 0.8 → 0.3 bar over 90 s · RACK-14/16 inlet +6.2 K · hall return +2.1 K
- Inferred
- Coolant flow restriction upstream of CDU-2E. Rack symptoms are downstream, not independent faults.
- Confidence
- Medium — consistent with two prior events on this loop; no flow meter on the affected branch.
- At risk
- Loop 2E · 14 racks · N+1 already consumed by scheduled work on CDU-2F.
- Margin
- ≈ 11 minutes of thermal headroom at current load before inlet exceeds class limit.
- Response
- Qualified on-site engineer with CDU authorisation · MOP-114 attached · escort not required.
- Approval
- Requires named human approval before dispatch. The system does not act on this alone.
- Closes when
- Δp holds ≥ 0.7 bar for 30 min AND rack inlet returns to baseline AND the engineer confirms the cause found.
A decision record holds what a phone call does not:
- Observed evidence, and the inferred condition it supports.
- Confidence in that inference, and the thermal margin remaining.
- The authorisation required, and the response proposed.
- The named people permitted to perform it tonight.
- The physical condition that will count as recovery.
What this cannot do
Any layer proposing to sit above the BMS has to answer the control question first, because the honest answer is what makes it deployable in a live facility. A critical site will not connect something that could move a setpoint, and it should not.
This one reads state. It does not write setpoints, command equipment, or hold authority over any physical device.
- Reads: BMS points, DCIM topology, CMMS asset and work history.
- Writes: a decision record, and a work order into the system of record.
- Never writes: a setpoint, a command, an equipment state.
- Never holds: safety-critical approval, which stays with a named human.
That boundary is not a limitation to be engineered away later. It is what lets a critical facility connect it at all.
Answered
How long should the alarm-to-dispatch interval be?
There is no published benchmark for cooling, which is part of the problem. IT incident practice tracks mean time to acknowledge and treats minutes as the unit; critical facilities rarely produce the equivalent figure for a cooling event. Measure your own three incidents first, then judge the number against your thermal ride-through rather than against an industry average that does not exist.
Who should own the interval?
Ownership usually has to be assigned rather than discovered, because the interval crosses the boundary between the controls team who see the alarm and the operations team who dispatch. In practice the shift engineer owns it by default and without instrumentation. Naming an owner is worth doing even before any tooling changes, because it makes the handover visible.
Does a longer interval always mean a worse outcome?
Not on its own. An interval of forty minutes on a unit with hours of thermal margin may be entirely appropriate, while four minutes on a hall at 95% of cooling capacity may already be too slow. The number only means something against the margin remaining, which is why margin belongs in the measurement.
Is this just alarm correlation?
Correlation is the first step and the easiest part to buy. The harder part follows it: deciding whether a correlated event is an emergency given the margin remaining, selecting a person by competence and authorisation rather than proximity, and refusing to close the incident until physical telemetry says the condition is gone.
Does it replace the BMS, DCIM or CMMS?
No. It reads them and writes work into them. The BMS keeps controlling equipment, the DCIM keeps modelling the facility, and the CMMS stays the system of record for work. What is new is the layer that decides between them, which none of them was built to do.
Why does the interval not show up in our incident reports?
Because incident reports usually start when a ticket is raised, and the ticket is raised after the judgement has already been made. The minutes before it are invisible to the record, which is why a site can hold a strong response-time figure and still lose hours. Measuring it needs the BMS event log and the dispatch log side by side.
Is this an alerting or on-call product?
No. Alerting and on-call products shorten delivery time, and the good ones do it very well. This page is about the judgement made after delivery and before dispatch: whether a correlated event deserves a response tonight, which procedure applies, and who is both qualified and authorised to give it. That judgement is currently made by a person, from memory, and no system records it.