Your cameras show live video: how do you know they are recording?
In short
Live video only proves the camera and the network are alive. Recording stops for its own reasons — a full or dead disk — and the live view keeps working. Most people find out when they need the footage. Watch the recorder, its disk and its clock, and check the playback yourself once a month.
Someone opens the app, sees the live image and concludes the system works. It is the most natural mistake in video surveillance, and also the most expensive: live video proves the camera has power and the network is alive. It proves nothing about what is being written to disk.
Why does recording stop while the live view keeps working?
Recording and live view are two separate jobs inside the same box. A recorder can keep serving images while it has stopped writing them, and the manufacturers say so themselves.
In Milestone XProtect, when a recording storage becomes unavailable the recording server stops writing while the live view continues; the safe behaviour, stopping the server so the failure is visible, is an option that is switched off by default. Genetec lists the same family of causes in its own documentation: the recording mode, a schedule, the archiver database, missing free space, a lost transmission. Their troubleshooting page also tells you how customers notice: they cannot find the playback for a specific date and time.
The usual culprits are unglamorous: a disk that died, a disk that filled up, network storage whose credentials changed, a schedule someone set to motion-only and forgot.
How do people find out today?
Too late, and in front of someone. Among IT professionals the story is told almost word for word: the moment the client and the police are waiting for footage is the moment you discover the recorder’s disk died a month ago. A security manager at a financial institution described years of the same pattern: time after time there simply was no video, and it was discovered only after an incident.
There is a second, quieter failure: the clock. A recorder whose time has drifted by minutes produces footage whose timestamps do not match the door log, the till receipt or the phone record. Industry guidance on surveillance time sync is blunt about it: manual time setting is easily forgotten, and a wrong time can make video easy to challenge.
What can you actually watch over the network?
Quite a lot: that the recorder answers, that the port serving video is still listening, how full the disk is, and whether the time server is answering — as long as we are precise about what each check proves.
- The recorder answers. If it stops responding, you hear about it in minutes instead of weeks. This is the floor, not the ceiling.
- The port that serves video is still listening. It is a stronger signal than a ping, because the service can die while the box stays up. It does not prove that images are flowing: only your own playback test does that.
- The disk. Where the device exposes it, we read free space and health, follow the trend and tell you “full in about N days”, with a warning at 14 and at 7 days. A full disk is the most common reason recordings stop.
- The time server. If your cameras and recorder take their time from an NTP server, we watch that server: a clock that has nothing to sync to is the way drift starts. The camera’s own clock we cannot read — you compare it by hand, and that is point 4 below.
- The certificate of the web interface, so the page your installer uses does not break on a Saturday.
What to do this week
- Write down which recorder, which disk, which retention. If nobody can answer, that is the first finding.
- Watch the recorder and its disk, so you learn about a problem while it is still cheap.
- Play back a random old recording. Note the date of the test.
- Check the recorder’s clock against a reliable source.
The goal is not to trust the green light. It is to make the silent failure noisy.
What we cannot tell you
- We cannot tell you that a camera is recording: no standard exposes that state over the network, and we will not claim it until a check exists that proves it.
- We cannot tell you what the camera is pointing at, whether the lens is dirty or whether someone moved it.
- We cannot tell you that a recording will play back: only your own playback test proves that.
- We cannot read the clock inside a camera or a recorder: we can watch the time server they are supposed to follow, and you compare the clock yourself.
Questions people actually ask
Why does live video work while nothing is being recorded?
Because they are two different jobs. Live video is read from the camera and shown on screen. Recording means writing to a disk, on a schedule, with enough free space. If the disk is full, failing or unreachable, the writing stops while the reading continues — and nothing on the screen looks wrong.
How do most people discover that the recorder stopped?
When they need the footage: after a theft, with the police or the insurer waiting. In public discussions among IT professionals the same sentence comes back: the disk had died weeks earlier and nobody had noticed. It is the worst possible moment to find out.
What can monitoring actually see on a video system?
That the recorder still answers on the network and that its web interface is up; that the port serving the video stream is still listening; how full the disk is and in how many days it will be full, where the device exposes that over SNMP or SSH; and whether the time server your cameras follow is answering, which matters because a wrong timestamp makes footage easy to challenge.
What should I check myself, and how often?
Once a month, play back a recording from a random day and hour, not from today: it is the only test that proves the whole chain worked. Note the date you did it. It takes two minutes and it is the difference between believing and knowing.