How to actually reduce camera notification latency: a hop-by-hop budget for the chain between “person walks past the camera” and “phone buzzes in someone’s pocket.”

The chain has six hops, not one

The phrase “notification latency” flattens a pipeline that has at least six distinct stops. Each one has its own dominant cost, its own failure modes, and its own knobs. Tuning the wrong one buys you nothing. Below is the chain in order, with the typical millisecond cost when everything is healthy.

Add those up and a healthy local pipeline lands at roughly 2 to 5 seconds. A consumer-grade chain that round-trips through a cloud rules engine, a third-party push service, and a doze-batched phone can extend the same chain to 30, 60, or 90 seconds. Same model. Same camera. The difference is which hops live where.

Hop 1: camera to recorder

A frame leaves the image sensor and lands on the recorder. On a wired LAN this is sub-second and effectively free. On a flaky Wi-Fi camera with a weak signal, the same hop can spike to multiple seconds when packets retransmit. This is the one hop where the standard advice (wired ethernet, place the router closer, reduce contention) actually buys you the milliseconds it claims.

If your alerts are arriving 30 seconds late on a wired system, this hop is not your problem. If you are on Wi-Fi and the camera is two walls away from the router, it could easily be hundreds of milliseconds of variable delay. Move it to ethernet and stop tuning.

Hop 2: recorder to inference

This is where most architectures secretly bleed time and most product pages will not tell you. There are three patterns:

• Camera-side detector. Each camera runs a small model on its own chip. The detection event is local to that camera, but it then ships out to wherever the rules engine lives. The hop after the model is the one that matters.
• Cloud detector. The recorder uploads frames or clips to a cloud GPU pool. The model latency is competitive but you have just paid for an entire upload to start the inference. Add the WAN.
• Local sidecar reading the recorder.A box on the same LAN as the recorder reads the recorder’s output (over HDMI, on Cyrano) and runs inference on the same machine. The hop is a memory copy. Cost is on the order of milliseconds, not seconds.

The third pattern is the only one where this hop is essentially free. The first two pay anywhere from a hundred milliseconds to several seconds, plus all the failure modes that come with any link that has to be up and healthy at the moment something happens.

Hop 3: the model

On a current edge accelerator, a person-and-vehicle detector running on an HDMI tile grid takes about 100 to 400 milliseconds per tile, depending on resolution and how many objects are in frame. The variance is in the second number, not the first. A clean tile resolves fast. A tile with five overlapping people in low light takes longer.

This is the hop everyone assumes is the bottleneck and almost never is. Unless the system is running on under-spec hardware, the model is hundreds of milliseconds, not seconds, and tuning it harder mostly buys you false-positive reductions, not raw speed. The wins are on either side.

Hop 4: the dispatcher decision

The model produces a structured event: person, side-gate zone, 0.91 confidence, 02:11:03. Something has to decide whether that becomes an SMS, an outbound phone call, both, or just a row in the morning digest. That “something” is the dispatcher, and where it lives determines whether your alerts are 2 seconds late or 30 seconds late.

On most consumer camera systems and many small business systems, this decision lives in a cloud control plane. Every detection round-trips to a server, the server evaluates rules like “after-hours equals HIGH,” and the dispatcher fires from the cloud. Round trip on a healthy uplink: 200 to 600 milliseconds. Round trip on a saturated upload during a storm: anywhere from a couple of seconds to no answer at all. This is the hop that turns a 3-second chain into a 60-second one when the WAN is unhappy.

The fix is structural, not configuration. The dispatcher needs to be on the same machine as the model. Cyrano keeps detect, dedup, classify, and dispatch on the box itself. The cloud is on the egress path only, used to actually send the SMS, place the call, and update the dashboard. The decision that fired them was already local.

Hop 5: the SMS carrier hop

This is the floor. Once the dispatcher decides to send, the SMS goes out through a carrier gateway and an outbound phone call goes through a voice provider. End to end, both land on the destination phone in 1 to 3 seconds when everything is healthy. Sometimes 4 if the carrier is congested.

You cannot collapse this hop. It is not in your settings menu. It is not in your camera app. It is the cost of running on the public phone network, which is the only network the operator’s phone is reliably reachable on at 2 a.m. The right move is to budget for it and not waste effort trying to optimize underneath it.

Hop 6: the phone OS

Last hop, and the one most people never think about. iOS Low Power Mode and Android battery saver delay non-priority pushes so the radio can sleep. A push that would have arrived in 800 milliseconds can land 30 seconds later, sometimes longer if the phone has been idle. The behavior is documented; it is not a bug. The OS is doing exactly what it was designed to do.

The reliable workaround for high-priority events is a real outbound phone call rather than a push. Phone calls bypass the doze-batching logic because they go through the cellular voice path, not the data push path. This is also why an SMS plus an outbound call is the right pair for HIGH events, and a push alone is fine for LOW events that can wait until the operator wakes the phone. If you are evaluating systems and the only delivery channel is an in-app push, you are downstream of the phone’s mood.

What you can change today, in order of impact

Sorted by how much millisecond-or-second time the change actually buys you. Top of the list first.

1. Move the dispatcher onto the LAN. If your camera vendor evaluates rules in a cloud control plane, every event is paying a WAN round trip on the way to the SMS. The fix is a box on the same network as the recorder that runs detect, dedup, classify, and dispatch in one process. This is the largest single change you can make to your alert latency, and it is the one no settings menu offers.
2. Add a phone call channel for HIGH events.Pushes and SMS are subject to OS batching and carrier weirdness. A real outbound voice call goes through a different path that the phone’s battery saver does not throttle. The cost is low and the worst-case latency improvement is minutes, not milliseconds.
3. Move duplicate suppression into the inference layer.If your pipeline merges duplicates in a cloud notification layer, every detection is paying WAN time before the merge decision. Local merging using the model’s per-zone tracks is faster and produces better merges (one walk-through becomes one alert, not four phone calls).
4. Wire up cameras and recorders, not just suggest it. If the LAN hop is on Wi-Fi, every retransmission costs you. This is the smallest of the four wins on this list, but it is real and free if you have ports.

What is not on this list, despite being the standard advice: lowering motion sensitivity, shortening clip length, factory-resetting the camera, upgrading firmware. Those are useful, but they tune the detector. The detector is rarely the bottleneck. Tuning past it just buys diminishing returns on the cheapest hop in the chain.

How to test where your own lag actually is

One short test, no instrumentation needed. Stand in front of one of your cameras, wave for two seconds, and step out of frame. Note the wall-clock time. Wait for the SMS or push to land on the operator’s phone and note that wall-clock time. Subtract.

• Under 5 seconds. You are mostly waiting on physics. The carrier hop and the phone OS are the dominant terms. There is not much left to cut. Stop tuning.
• Five to fifteen seconds. A WAN round trip is showing up somewhere, probably the rules engine or the push fan-out. Worth investigating but not catastrophic.
• Fifteen to ninety seconds. Cloud round trip plus phone-OS batching. Two separate problems compounding. The dispatcher is in the cloud and your phone is in low power mode. Move the dispatcher local and add an outbound call channel.
• Over ninety seconds, or never. The link is failing some events outright. This is no longer a tuning problem; it is a design problem. The alert chain is depending on a cloud round trip that does not always succeed.

Repeat the test once on a healthy day and once on a busy weekday evening (when the property uplink is congested). The gap between the two is the gap that vendors with a cloud dispatcher quietly hide.

Why the structural fix beats every settings-page fix

Most pages on this topic give you a settings checklist. Lower the sensitivity, raise the retrigger window, update firmware, plug in ethernet. Each item buys back a small fraction of the chain. None of them touch the structural problem, which is that the rules engine and the dispatcher are on the wrong side of the WAN. A 50-millisecond improvement on the LAN does not help when the cloud round trip is the dominant term and behaves nondeterministically under load.

The honest answer for property operators with existing CCTV is: keep the cameras and the recorder you have. Add a sidecar box on the same LAN that ingests the recorder’s tile grid, runs the model and the dispatcher locally, and uses the WAN only for egress (SMS, voice call, dashboard sync). That is the architecture that keeps the alert chain under 5 seconds on a good day and under 30 seconds on the worst day. It is also the architecture that survives the property uplink dropping for nine minutes during a storm without losing any events. The settings checklist does not survive that. The structure does.