BRITISH COLUMBIA · SINCE 2015CALL A LOCAL TEAM — (604) 360-7400
(604) 360-7400Book a free site walk-through

How your alarm actually talks to the monitoring station

Alarm monitoring works by your panel sending a short coded message (account, event type, zone) over a phone line, internet or cellular path to a monitoring station, where a person acts on it. You can only trust it if that path is supervised, so a dead connection raises an alert instead of looking like a quiet night.

Guard Nation Security9 min readReviewed by Guard Nation's security systems teamLast reviewed

How does alarm monitoring work?

Your panel turns an event into a short coded message and sends it over a phone line, internet or cellular path to a monitoring station, where a person acts on it.

Everybody who buys a monitored alarm system buys the box. It is the part you can see: a metal enclosure in a closet, a keypad by the door, a row of sensors on the doors and windows. That is the part in the quote, and the part you point at when someone asks what you have.

None of it does anything on its own.

A monitored alarm is a message-passing system. Something happens at your building, the panel turns that event into a short message, and the message travels somewhere else — to a monitoring station staffed by people whose job is to act on it. The sensors can be perfect, the panel can be new, the programming can be immaculate, and if the message does not arrive, you own a very expensive noise-maker.

So the honest way to describe your system is not "we have an alarm." It is "we have a path" — and the path is the part almost nobody asks about.

What does an alarm monitoring station receive?

A short coded report, not video or words: which account, what kind of event, which zone or user, and whether the condition started or cleared.

It helps to know how small the message is, because the smallness explains most of what follows.

When your panel reports an event, it is not sending video, or a description, or a sentence. It sends a compact, structured report with a handful of fields:

  • Which account. A number identifying your site, which is how the station's software pulls up your address, your instructions and your contact list.
  • What kind of event. Burglary, fire, panic, trouble, low battery, restore, opening, closing. A defined vocabulary the panel picks from.
  • Which zone or which user. Zone 4, or user 12. A number, not a name.
  • New or restored. Whether the condition just started or just cleared.

The two long-standing reporting formats used across the industry — the one usually called Contact ID, and the family developed under the Security Industry Association's banner and generally referred to as SIA — are variations on that same idea: a terse coded report, not prose. We describe them here as formats; we are not citing a published standard for either.

Two consequences fall straight out of this.

First, the words come from the monitoring station's database, not from your panel. Your panel transmits "zone 4." Whether the operator sees that, or "Rear loading bay overhead door," depends entirely on how carefully somebody typed your zone list into the station's system and whether anyone updated it when the building changed. A zone list still reading "spare" three years after that zone was wired to a new server room door is a common failure, and it does not look like a failure from your side. Everything tests fine.

Second, the message is small enough that it does not need much of a connection. That is why alarm signalling survived for decades on the humblest link in the building, and why it can now survive on a cellular connection that would be useless for anything else. The path does not need to be fast. It needs to be there, and it needs to be known to be there.

A telephone service that carries your voice calls perfectly is not thereby proven to carry alarm signalling.

The telephone line: from default to liability

For most of the history of alarm monitoring, the path was an ordinary telephone line. The panel seized the line, dialled the monitoring station's receiver, exchanged a short burst of tones and hung up. It worked, it was everywhere, and it required no design decision from anybody — which is precisely why it became the default and why so many BC buildings are still running it.

The reason it is now a liability has nothing to do with alarms. Copper networks are being retired. TELUS, for example, is retiring its legacy copper lines wherever its fibre network is available, requires customers inside its copper-retirement boundaries to move to fibre or a wireless service, and reported 14 areas of BC and Alberta completely copper-free by the end of 2023. A service being retired underneath you is not a foundation for a property-protection function. At some point the countdown for your building becomes a date.

The more dangerous version of this has already happened in many buildings without anyone noticing: the line was replaced with a voice-over-IP service, and everything appeared fine.

Here is the trap, and it is worth reading twice. A telephone service that carries your voice calls perfectly is not thereby proven to carry alarm signalling. They are different jobs. A human conversation tolerates a surprising amount of degradation — a dropped syllable, a bit of delay, a compressed frequency range — because your brain patches over it and, if it gets bad enough, you say "sorry, say that again." Alarm signalling cannot say that again. It is a machine-to-machine tone exchange with timing expectations, running over equipment designed to optimize the sound of speech. Voice service also depends on powered equipment on your premises, which behaves differently in an outage than the old line did.

None of that means VoIP always fails. It means VoIP is not self-evidently fine, and "we still have a dial tone" is not a test. If your panel is still dialling out over a line that has been converted at any point, that is a thing to verify deliberately, not a thing to assume.

What replaced the phone line: IP or cellular?

A data path: an internet (IP) communicator on your building's network, a cellular communicator with its own radio, or both.

Diagram: an alarm panel sends events through a communicator over an IP path and a separate cellular path to a monitoring station, with regular supervision check-ins on each path.
Two independent paths, each checked on a schedule. A missed check-in is itself an event.

The modern answer is that the panel reports over a data path instead of a voice path. In practice that means one of two things, or both.

IP. A communicator connected to your building's network sends the report over the internet to the monitoring station. It is fast, it costs nothing incremental to send, and — this is the important part — it can be checked continuously.

Cellular. A communicator with its own radio and its own subscription sends the report over a mobile network. It has one structural advantage: it does not depend on anything in your building except power and antenna coverage. Nothing in your comms room, nothing your internet provider does, nothing an errant contractor unplugs.

Both are unremarkable technology at this point, and the interesting question is not which one you have. It is the next one.

Alarm signalling paths compared

Path

Depends on

How it fails

What to ask

Copper phone line

The carrier's copper network

Copper is being retired, and the line may already have been converted

Is our panel still dialling out over it?

Converted phone line (internet voice)

Powered equipment on site and the provider's voice service

Carries calls but is not proven to carry alarm signalling, and behaves differently in a power outage

Has it been tested for alarm signalling?

IP communicator

Your building's network and internet service

A firewall change, a dead modem, an internet outage

Is it supervised, and how often is it checked?

Cellular communicator

Power and antenna coverage

An expired data plan, weak coverage

Is it independent of our network and power?

Is a monitored alarm worth having?

Only as much as its path: a supervised path tells you within a known window when it fails, while an unsupervised one fails silently.

Here is the idea that separates a monitored system that will tell you the truth from one that will not.

Supervision means the path is checked on a regular, known interval, whether or not anything is happening. The panel and the monitoring station exchange a small check-in message on a schedule. Nothing is alarming; the message says, in effect, still here. If the expected check-in does not arrive, the station has learned something: the path to your building has failed. That becomes an event, it lands in front of a person, and somebody calls you.

An unsupervised path, by contrast, is silent unless there is an alarm — which means silence carries no information at all. A cut line, a failed communicator, an expired data plan, a firewall change made by an IT contractor on a Tuesday, a dead modem: all of these produce exactly the same thing on the monitoring station's screen as a peaceful, uneventful night. Nothing.

That is the whole point. On an unsupervised path, a broken connection and a quiet night are indistinguishable. You discover the failure the next time you need the system, which is the worst possible moment and possibly months away.

Readers of our piece on the wire between your card reader and the door will recognize this exactly — it is the same idea one layer down. The Security Industry Association describes the modern access-control protocol as offering supervised connections that indicate reader malfunctions; the "S" in OSDP is supervision, and it exists because a link nobody checks is a link that fails quietly. The alarm transmission path has the identical property, and it matters more here, because this is the link that carries the emergency.

The practical value of supervision is not the alarm signal. It is the interval. A supervised path converts "we might find out eventually" into "we will know within a defined window." That window is a design choice made when your system was configured, and it is a number you are entitled to be told. We are not going to print a typical figure here: it depends on your equipment, your monitoring provider and how your account was set up, and a number invented for an article is worse than no number.

Do you need a second path, and is yours really independent?

A backup only counts if it cannot fail together with the primary: it must not share your network, power supply or physical entry point, and it must be supervised too.

Once supervision is on the table, redundancy follows: two paths, so the failure of one does not take the system with it. Commonly that means IP as the primary and cellular as the backup, with the panel reporting over whichever is available.

The question to ask is not whether a second path exists. It is whether it is independent — whether the two can fail together. A backup that shares a critical component with the primary is not redundancy; it is decoration with a monthly fee. Things worth checking:

  • Does the backup share your building's network? A cellular communicator routed through your own router is not independent of your internet service.
  • Does it share a power supply? Both paths on the same unbacked outlet fail at the same instant. Backup power for the panel that does not extend to the communicator is a common gap.
  • Does it share a physical entry point? Two services entering through the same conduit fail together when that conduit is damaged.
  • Is the backup itself supervised? A standby path nobody checks is in exactly the condition described above: it looks fine because it is silent, and silence is not evidence. It can sit dead for a year and be discovered on the night it is needed.

That last one is the one people miss. Supervising the primary and not the backup means you find out promptly when the good path breaks, and never find out the safety net went with it.

The two questions to ask your provider

Everything above compresses into two sentences you can send in an email.

  1. "How would you know if our panel stopped being able to reach you, and how long would that take?" You are looking for a specific mechanism and a specific interval — the path is supervised, checked on this schedule, and a missed check-in raises this event to a person. If the answer is a general reassurance rather than a mechanism and a duration, the path may not be supervised at all. Ask for it in writing, per site.
  2. "Do we have a second path, and is it genuinely independent of the first?" Then walk the independence list above: network, power, physical entry, and whether the backup is itself supervised. An integrator who works with this regularly answers without hesitation.

Two more while you have their attention. Is the panel still dialling out over a telephone line, and has that line been converted to internet-based voice at any point? And: when did anyone last confirm the zone descriptions in the monitoring station's system match the building as it exists today? That second one costs nothing and is wrong more often than owners expect.

The short version

The panel is not the system. The path is. A message leaves your building carrying an account number, an event type and a zone number, and the entire value of your investment rides on whether that message arrives.

The legacy telephone path is being retired underneath you, and a converted line that still carries calls has not been shown to carry signalling. IP and cellular replace it. But what determines whether your system will tell you the truth is not which path you have — it is whether anyone is checking that the path is alive, how often, and whether the backup you pay for could fail without a sound.

An unsupervised path is quiet in exactly the same way as a safe night. Ask which one you are having.

For the adjacent piece — what happens after the signal arrives, and why the quality of your contact list decides the outcome — see false alarms and what they actually cost you in BC.

Written by the Guard Nation Security team — from the sites we install, monitor, guard and investigate across British Columbia, and have since 2015.
Sources

Sources

This article deliberately cites no standard for alarm signalling formats or supervision intervals, and states no check-in interval, because we have not read a primary source for either and an invented figure is worse than none. Confirm your own system's supervision interval and path configuration with your monitoring provider in writing.

Want fewer false alarms and a faster real one?