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 is actually in the message
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.
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. Traditional copper telephone service is being progressively wound down across North America as carriers move customers onto internet-based voice, and a service being decommissioned 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 a great 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.
IP and cellular: what replaced it
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.
The concept that actually matters: supervision of the path
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.
The second path, and whether it is genuinely a second path
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.
