The monitoring tier is a daemon running next to the recorder, not a call center at the end of a signaling line.
Run the search. ADT, SimpliSafe, Vivint, Brinks, Cove: every top result sells monitoring as an operator shift. UL-1610, two-call verification, dispatch surcharge, $30 a month. On a Cyrano deployment, the monitoring tier is a Linux process named cyranod, supervised by systemd, living next to the DVR. It reads frames every second, emits 9-key classified events, and restarts in 2 seconds if it crashes. This page is about that .service file, the event payload it emits, and why a daemon cannot be on another call.
See cyranod running on a live unitThe SERP framing: systems trip, humans answer, dispatch follows
Read the top ten search results and the shape is identical. A product page lists a camera kit, a sensor kit, and a monthly monitoring fee. The monitoring fee entitles the customer to a staffed central station. The central station is UL-1610 listed. It is staffed 24/7. Its job is to receive a signal from the customer's panel, call the customer, extract a passcode, and dispatch police if no passcode arrives. The signal format is SIA Contact ID over IP radio or cellular. The monthly fee is roughly $30, with per-dispatch surcharges and per-false-alarm fines from the municipality on top.
Nothing about this model is wrong. It just has a fixed shape: every alarm travels through a telephone-era queue to a meatspace operator who makes a judgment call. The monitoring tier is a roster, and the roster's capacity scales with headcount. When a storm hits the region, the queue is long, and the operator who would have called a property manager about a 3am mailroom event is instead cycling through 200 storm-induced trips.
This page is about a different shape. The monitoring tier is a process. It lives on the property, not at the station. It has no roster. It has a unit file.
Five things the daemon does that an operator structurally can't
Not a marketing list. A list of structural differences between a process and a person on shift. Each one is observable from the event stream.
Watch 25 tiles at once
cyranod evaluates every visible tile on the DVR multiview every second, all in parallel. An operator holds one call at a time and watches one screen at a time. On a 25-camera property, the daemon's concurrency is 25x.
Emit structured output
Every event is a 9-key JSON object. A call is a voice stream. You can pipe the daemon's output to a dashboard, a SIEM, or an insurer's portal without transcription.
Cost $0 per event
$200/mo flat per property whether the daemon fires 0 or 10,000 events. Central stations bill per-dispatch surcharges and local municipalities bill per false alarm. A month of weather flips the economics.
Recover in 2 seconds
Restart=always in the unit file means a crashed monitoring tier is a 2-second outage, not an hours-long staffing gap. The heartbeat catches it at the 90-second threshold if restart ever fails.
Run on a 2-call-free night
A daemon does not forget to answer. It does not miss a second shift. It does not apply two-call verification to a 3am package-removal event. HIGH_THREAT emits to SMS and voice in 7 to 8 seconds, every time.
The unit file that turns monitoring into a system service
This is the file installed at first-boot provisioning on every Cyrano edge unit. systemd reads it, enables it, and from that point on the "monitoring" is a thing systemd supervises. The Restart=always clause is the operational equivalent of a shift change that takes 2 seconds. The ReadWritePaths clause scopes where the daemon may write, which in turn scopes where the heartbeat and event index live.
What the daemon actually emits, byte for byte
The substitute for an operator's phone call is this JSON object. 9 keys, same shape every time. It carries the property, the camera, the class, the graded threat level, a dwell time in seconds, a confidence score, a timestamp on the property's local clock, a thumbnail URL, and the end-to-end latency. The property manager receives this on their phone as an SMS with an inline thumbnail, or as a WhatsApp message, or as a webhook POST to their own stack.
Central-station monitoring vs. daemon monitoring, side by side
Neither column is categorically wrong. The traditional column is the right tool for intrusion-alarm signaling, which is a legal and insurance category with its own UL listing. The Cyrano column is the right tool for video-verified event monitoring on a multi-camera property, which is where the SERP's framing starts to break at scale.
| Feature | ADT / SimpliSafe / Brinks (central station) | Cyrano (daemon on edge unit) |
|---|---|---|
| Monitoring tier is | A staffed call center (UL-1610) | A systemd unit on the edge box (cyranod.service) |
| Alerting primitive | Phone call with passcode verification | 9-key JSON event with thumbnail + class + dwell + confidence |
| Concurrency ceiling | 1 operator per call at a time | 25 tiles evaluated per second in parallel |
| Recovery from a failure | Operator returns from break, shift swap, storm backlog | Restart=always, 2-second process restart |
| Signaling protocol | SIA Contact ID over IP radio / cellular | HTTPS POST + SMS + webhook, no signaling line |
| Per-event marginal cost | Per-dispatch surcharge + municipal false-alarm fine | $0 per event, $200/mo flat per property |
| End-to-end latency | ~2 minutes (two-call verification) | 5 to 15 seconds (median 7 to 8) |
| Audit trail artifact | Phone call audio + operator notes | Structured event log + thumbnail + latency_ms per emit |
The two signaling paths, drawn at the event level
Same starting point on both paths: something happens on a camera. What happens next determines how fast and how structured the alert is by the time it reaches the person who can decide.
event path: central station vs. cyranod
Frames in, classified events out, over one TCP connection
Every input to the daemon is a frame off the recorder. Every output is a classified event on one of three channels: a SIEM or dashboard webhook for LOW_THREAT, an SMS for the property manager with an inline thumbnail, and a voice call for HIGH_THREAT. The daemon itself is the only thing at the middle. No operator, no queue, no shift schedule.
inputs to the daemon, outputs from the daemon
A live daemon, from the SSH prompt
This is what the monitoring tier looks like from a shell. The unit is active and has been running for 4 weeks 5 days. The heartbeat file was written 4 seconds ago. The last six events include HIGH_THREAT emits to SMS, voice, and webhook, plus a classifier hit that was dropped because it fell below the confidence floor. None of that exists on a central-station model; the operator's judgment is not a queryable log.
“At one Class C multifamily property in Fort Worth, the cyranod daemon emitted 20 structured events in the first month, including a break-in attempt, each one arriving at the property manager's phone in under 15 seconds with a classification, a dwell time, and a thumbnail. The monitoring tier was a process the whole time. No operator was in the loop.”
Cyrano field notes, Fort Worth property
The numbers, flat across every month
Here is the structural math. The daemon costs and performs the same in a 0-event month and in a 10,000-event month. The central-station model does not.
Across more than 0+ production properties, the daemon has held the same shape: one unit file, one heartbeat, one 9-key payload, one flat subscription. The latency typically lands at 0 to 15 seconds from frame capture to the recipient's phone.
Words that apply to a call center and not to a daemon
None of these terms describe a process. They describe a roster. The daemon swaps the roster for systemd.
The thing that is uncopyable
cyranod.service is the monitoring tier.
On a Cyrano unit, /etc/systemd/system/cyranod.service is the ~20-line file that makes monitoring a system service. Restart=always means a crash is a 2-second outage. The heartbeat at /var/lib/cyrano/heartbeat is mtime-checked every 90 seconds. The 9-key event payload is the shape of every emit. No operator, no shift, no passcode exchange, no per-dispatch surcharge. The "monitoring" is a program the kernel supervises, not a person the station supervisor supervises. When ADT's central station is 8 operators deep in a storm queue, cyranod is running at 612 MB resident and emitting sub-10-second events. That is not marketing. That is the daemon's job description.
When the call-center model is right, and when the daemon model is
For a single-family home with a perimeter alarm panel and no cameras, the call-center model is right. The signaling is sparse (a few zone trips per year), the liability path is well defined (UL-1610 central station, police dispatch), and the insurance premium credit is tied to that listing. The SERP's framing maps the buyer's reality exactly.
For a 40-building multifamily portfolio with 25 cameras per property and mailroom-and-lobby incident rates measured in events per week, the model breaks. The per-dispatch surcharge grows linearly with weather. The operator cannot watch 40 properties at once. The phone call is not a structured record the insurer can audit. In that window, the monitoring tier wants to be a daemon. A .service file per property, a 9-key payload per event, a flat $200/mo subscription, and a 2-second recovery clause at the bottom of the unit file. That is the window this page is for.
See cyranod running on a live property
A 15-minute call. We SSH into a production Cyrano unit, show the systemd status, tail the journal, and walk an event from frame capture to the thumbnail that lands on a property manager's phone.
Book a call →Security systems and monitoring: frequently asked questions
What does the top SERP for 'security systems and monitoring' actually sell?
A human-staffed central station on the end of a signaling line. ADT, SimpliSafe, Vivint, Brinks, Cove, Frontpoint, and Alder all describe monitoring as a 24/7 call center. The system (hardware) trips a zone, the signal reaches the central station over IP radio or cellular or a dying POTS line, and a staffed operator calls the homeowner, waits for a passcode, and dispatches police if the passcode does not come back. The marketing bullets are 'UL-1610 certified,' 'U.S.-based monitoring professionals,' '24/7/365 staffing,' and a monthly fee starting around $30. The monitoring tier is, literally, people on shift. None of the top results describe monitoring as a process on a server, because for alarm monitoring it is not.
What does it mean that Cyrano's monitoring tier is a daemon instead?
cyranod is a long-running Linux process that starts at boot under systemd. It reads frames from the DVR/NVR HDMI input, runs on-device inference every second, evaluates each tile against configured zones and event classes, emits structured event payloads over HTTPS (and via SMS or WhatsApp), and writes a heartbeat every 30 seconds. Its unit file is /etc/systemd/system/cyranod.service with Restart=always, so a crash is a restart, not a staffing gap. There is no phone number that rings an operator. There is no passcode exchange. The monitoring output is a JSON payload, not a phone call, and the recipient is the property manager (via their phone), not a dispatcher.
Why does the distinction between a call center and a daemon matter to a property manager?
Four reasons. First, cost scaling: a central station bills per line (~$30/mo) plus per-dispatch surcharges, and a property with false-alarm fines in a dispatch-heavy month gets expensive. A daemon costs the same whether it fires 0 or 10,000 events in a month; Cyrano's $200/mo is flat. Second, parallelism: one operator can hold one call at a time. cyranod evaluates up to 25 camera tiles per second concurrently. Third, latency: alarm dispatch is multi-minute because it includes a verification call. Daemon-emitted events reach a property manager's phone in 5 to 15 seconds. Fourth, output shape: a central station produces a phone call; a daemon produces a structured event with a thumbnail, an event class, a dwell time, and a confidence score that can be piped into a dashboard, a PDF report, or a webhook.
What does the cyranod systemd unit file actually look like on a production Cyrano unit?
It is a ~20-line .service file at /etc/systemd/system/cyranod.service with a [Unit] block (description, wants network-online.target, after local-fs.target), a [Service] block (Type=simple, ExecStart=/usr/local/bin/cyranod --config /etc/cyrano/cyranod.toml, Restart=always, RestartSec=2, StandardOutput=journal, StandardError=journal, a handful of hardening flags like ProtectSystem=strict and NoNewPrivileges=true), and an [Install] block (WantedBy=multi-user.target). systemctl enable cyranod activates it. After that, the monitoring is a thing systemd supervises, not a thing a supervisor on shift supervises.
What is actually in the event payload cyranod emits?
A narrow, schema-bounded JSON object with 9 keys, and no more: property_id (matches the provisioning file), camera_id (the tile label the DVR overlays), event_class (loitering, tailgating, package_taken, vehicle_entry_off_hours, mailroom_linger, threat_high), threat_level (LOW_THREAT or HIGH_THREAT), dwell_seconds (how long the subject has been in the zone), confidence (0.00 to 1.00 from the classifier), ts_iso (ISO 8601 timestamp on the property's local clock), thumb_url (480x270 tile crop hosted on the unit or proxied), latency_ms (capture-to-emit in milliseconds). Nine fields, same shape every time. Readers that want to pipe the stream to a SIEM, a dashboard, or a CRM do not need to negotiate a schema; the contract is fixed.
How does a daemon handle what an operator handles, which is judgment?
It substitutes graded numeric signals for human judgment. An operator calling a homeowner uses subjective language: 'I see activity, it looks suspicious, do you want dispatch?' cyranod emits threat_level=HIGH_THREAT only when dwell_seconds crosses a zone-specific threshold, confidence crosses the calibrated floor, and the event_class matches a class the property manager has enabled for that zone. HIGH_THREAT triggers a phone call to the on-call and an SMS with the thumbnail. LOW_THREAT goes to the dashboard without waking anyone. The rules are declarative in the unit's config file, so two properties with different risk profiles can tune the thresholds independently. The daemon is not making judgment calls; it is firing on rules.
What breaks on the call-center model that the daemon model sidesteps entirely?
False-alarm fines. Passcode fatigue. Operator backlog on weather nights. Misrouted dispatches because the address on file is stale. Line supervision failures when a panel cannot reach the central station. The two-call verification clause that assumes a homeowner will answer a 3am unknown number. The per-dispatch surcharge that turns a busy month into a $600 bill on top of the monitoring fee. None of these apply to a daemon because there is no operator, no dispatch chain, no phone number to the central station, and no per-event fee. The daemon's failure modes are process failure modes (crash, OOM, disk full) which are handled by systemd restart and heartbeat monitoring, and the longest unmonitored window is typically 2 to 3 seconds.
Does replacing central-station monitoring with a daemon mean no one is ever dispatched?
No. Dispatch still happens; it is just triggered by a human who received a rich event, not by a human making a judgment call on a grainy signal. A HIGH_THREAT event with a thumbnail and a zone label reaches the property manager's phone with everything needed to decide whether to call police or call the on-site maintenance tech. The decision is the manager's, informed by a visual and a class label, not an operator's. This is why we route HIGH_THREAT events as a phone call and SMS to the manager, and leave 911 the human choice at the property, not at the station.
What exactly is the monitoring SLA on a daemon?
Three numbers. First, heartbeat interval: cyranod writes /var/lib/cyrano/heartbeat every 30 seconds; a watcher on the property or at the cloud control plane alerts if the mtime drifts past 90 seconds. Second, event latency_ms, recorded on every event payload, which typically lands at 5 to 15 seconds from frame capture to delivery. Third, uptime: because Restart=always and the unit is single-purpose, process uptime tracks hardware uptime and tends to exceed 99.9% per month. By contrast, a central station's SLA is an abstract staffing commitment, not a measurable signal you can read from your own property.
If this is a daemon, is it 'monitoring' in the sense that insurance and lease contracts mean by the term?
It is the substantive act of monitoring (continuous watching, structured alerting on events, auditable records), but it is not UL-1610 burglar alarm monitoring, which is a specific legal and regulatory category. Insurance policies that require UL-listed central-station monitoring for premium credits still require a UL-listed central station; Cyrano does not replace that for the intrusion-alarm line of coverage. What Cyrano does replace is human video monitoring ($3,000+/mo per site for a watching guard) and ad-hoc after-the-fact review. For liability, insurers increasingly accept 'video verified' events, and Cyrano's thumbnail + classification payload is exactly that. The daemon is complementary to the alarm panel, not a drop-in for a UL central station.
Comments (••)
Leave a comment to see what others are saying.Public and anonymous. No signup.