SNMP for CCTV: Check the Camera and Its Video

CCTV monitoring needs two checks: the camera is reachable and its video still produces fresh frames. SNMP queries network-device status; RTSP carries access to the video. Combine both where supported. Keep device-unreachable and frozen-video alerts separate so technicians know which part of the system to investigate.

A camera can stop working while the analytics pipeline and dashboard still appear healthy. The missing signal is: whether the device itself was still there.

I monitor camera fleets with SNMP for exactly this reason. It's an old, widely used protocol on managed network equipment. Camera, NVR, and PoE-injector support varies by model and firmware. Check documentation and enable it only on a restricted monitoring network.

SNMP is the boring layer, and that's why it works

SNMP (Simple Network Management Protocol) is a request/response protocol for asking a device about itself: is it up, how long has it been up. It also asks what's happening on its network interfaces.

Every value lives at an OID (object identifier), a dotted address into the device's MIB, its catalog of available data. Three OIDs cover most of what a camera fleet needs day to day:

• 1.3.6.1.2.1.1.3.0 — sysUpTime, time since the SNMP management subsystem last reinitialized, as defined in RFC 3418, in hundredths of a second. A reset can indicate a reboot or an SNMP-agent restart; counter wraparound also needs to be distinguished.
• 1.3.6.1.2.1.1.1.0 — sysDescr, the vendor's self-reported hardware and firmware string, useful for confirming what you're actually polling.
• 1.3.6.1.2.1.2.2.1.8 — ifOperStatus per interface, whether a link is operationally up. Administrative state uses a separate ifAdminStatus OID. On a PoE switch this tells you which downstream port just dropped, often before the camera itself stops answering.

None of this requires vendor-specific tooling. MIB-2 OIDs work across vendors when the device exposes those objects.

Polling from a Node backend

For the Node backends I build for these deployments, I reach for net-snmp. It's a JavaScript implementation of SNMP v1, v2c, and v3, published under the MIT license. It gives you a session object with get(), getBulk(), walk(), and subtree(). There's also trap and inform support, if a device is capable of pushing alerts instead of waiting to be polled.

The minimal poll below uses public only as an example. Restrict network access and prefer authenticated, encrypted SNMPv3 where supported:

const snmp = require("net-snmp");

const session = snmp.createSession(camera.ip, "public", { version: snmp.Version2c });

session.get(["1.3.6.1.2.1.1.3.0"], (error, varbinds) => {
  if (error) {
    markUnreachable(camera.id);
  } else if (snmp.isVarbindError(varbinds[0])) {
    recordMonitoringError(camera.id, snmp.varbindError(varbinds[0]));
  } else if (snmp.isVarbindError(varbinds[0])) {
    recordMonitoringError(camera.id, snmp.varbindError(varbinds[0]));
  } else {
    recordUptime(camera.id, varbinds[0].value);
  }
  session.close();
});

Run that against every device on the camera VLAN every 60 seconds. That gives you a reachability and uptime baseline for the whole fleet, switches included. No vendor SDK gets touched. getBulk() retrieves interface-table counters in batches, reducing round trips. Large tables can still require multiple requests. It starts to matter once per-OID polling takes longer than the polling interval itself.

What SNMP can't see

This is the part that trips people up: a camera can answer SNMP correctly, uptime climbing, interface up, ping healthy. Meanwhile the actual video feed is frozen. Picture a car with the engine running and the speedometer moving normally, but the dashcam died a while ago. The dashboard says everything's fine; only the engine actually is.

The chip that runs the network stack and the pipeline that encodes frames are different subsystems on cheap camera hardware. A fault in the encoder or sensor doesn't necessarily take the network stack down with it. I've seen a camera hold a healthy SNMP session for hours after its RTSP stream had already stopped producing new frames.

Checking RTSP health properly means going past "did the connection open." A plain OPTIONS request against an RTSP URL is unreliable for this. Some cameras respond fine while otherwise stuck. Some error on streams that are actually healthy.

What works is a frame-age watchdog: open the stream, and track the timestamp of the last frame actually decoded. Alert once that age crosses a threshold. That threshold is usually 30 to 60 seconds, enough margin to avoid flooding on ordinary bitrate hiccups. A periodic ffprobe check can confirm that frames decode during the probe. To track gaps continuously, retain a local last-decoded-frame time. So does a small consumer process using an RTSP/FFmpeg binding, without recording or displaying the video.

SNMP and the RTSP watchdog are answering two different questions, and a fleet dashboard needs both:

Device-down and stream-stale are different failure classes. One is usually a network or power problem. The other is usually a sensor, encoder, or storage-card fault, on a device that's still fully reachable on the network. Collapsing both into one status light loses the information that tells you which one you're dealing with.

Alerting: the same outage, two very different costs

A camera going dark for five minutes at 3 AM on a quiet loading dock is noise most nights. A PoE port blipped, the switch rebooted, it's back.

The same five-minute gap on the one camera covering an entrance is a different story. Discovered three days later while pulling footage for an incident review, that's the failure that actually costs something.

SNMP polling alone can't tell these apart; it just reports "was reachable" or "wasn't." The alert design has to carry that judgment instead:

• Debounce transient flaps. Require the failure to hold across two or three poll cycles before paging anyone, or every switch reboot becomes a 3 AM alert.
• Weight cameras by what they cover, not by device count. A parking-lot camera with a five-minute gap is a log line; an entrance or cash-point camera with the same gap is a page.
• Track downtime duration per camera, not just current state. That way a camera flapping every twenty minutes shows up in a weekly report, even though it's "up" at any given check.

Fleet dashboard basics

The dashboard itself doesn't need to be elaborate. A table of camera, last SNMP response, uptime, last good frame timestamp, and current alert state covers the operational question: what's down right now. That's true for a fleet of any size I've worked with.

Both signals write into the same status store and read back as one row per device. Wiring that kind of ingestion into a live dashboard follows the same pattern covered in the guide to IoT backends. What catches incidents isn't a fancier UI. It's making sure both signals are collected before the day someone needs to answer "was this camera even working."

None of this replaces getting the camera itself hardened and configured correctly in the first place. See the firmware hardening checklist for what has to happen before a camera goes live. Monitoring tells you when a correctly configured device has stopped behaving like one. A camera that was never configured right will fail in ways no amount of polling catches.

The takeaway

A dead camera is cheap to detect and expensive to discover late. SNMP gives you reachability and uptime for free, across every device on the network, where the devices expose the required SNMP objects.

It won't tell you the stream froze; that needs a frame-age check against the actual RTSP feed. Run both, alert on them separately. The failure that used to surface during an incident review shows up instead on a dashboard according to the configured polling and alert thresholds.