How long is jobsite camera footage kept?

The short answer, and the maths behind it

Every camera system answers this question the same way underneath, whatever the marketing says: retention equals available storage divided by the rate at which video is written. Nothing else is involved. If a system records at a given quality across a given number of cameras, it produces a predictable volume of video per day, and the drive holds a predictable number of those days before it starts overwriting the oldest footage.

That is why an honest answer to how long footage is kept has to be configuration-specific rather than a headline number. Camera count, resolution, frame rate, compression and how much of the day the system records all change the answer, and they change it by multiples rather than by percentages. A provider who quotes a single retention figure across every deployment is quoting a marketing number.

On SiteFortress360 units, recording happens locally on the unit itself, on solid-state storage inside the locked enclosure. Retention for your deployment is confirmed as part of the setup rather than asserted here, because the honest figure depends on how many cameras you have and what the site generates. What is worth understanding before that conversation is the shape of the answer, because it explains why the clip you want is sometimes there and sometimes gone.

Two clocks: continuous recording and event clips

The most useful thing to understand is that a modern unit is not keeping one kind of footage. It keeps a continuous record, which is heavy, and it keeps event material — detection clips, snapshots and the metadata that makes them searchable — which is light. Those two age at completely different rates, and confusing them is the reason people are surprised in both directions.

The continuous record is the one under pressure. It is every camera, all the time, and it is what gets overwritten oldest-first when the drive fills. This is the footage that answers open-ended questions: what happened in that corner last Tuesday afternoon, who was on site before the delivery, what did the yard look like before the damage. It is the most valuable footage when you need it and the first to disappear.

Event material is a fraction of the size, because a detection clip is seconds rather than hours and a snapshot is a single frame. A site can therefore hold a long searchable history of every person and vehicle the AI detected while holding a much shorter window of the continuous video behind those events. In practice this is the right trade: the events are what you search, and the continuous record is what you fall back to when the event you care about was not detected as one.

The operational upshot is simple and it is the single most useful thing on this page. If something matters, export it now. The clip is not safer for sitting on the unit, and the busiest weeks — which are the weeks something is most likely to happen — are exactly the weeks the continuous record ages fastest.

• Continuous video — heavy, overwritten oldest-first, the shorter clock
• Event clips and snapshots — light, searchable, usually survive far longer
• Detection metadata — smallest of all, and what makes the history usable
• Exported footage — outside the retention window entirely, and permanent

Why a busy site records less history than a quiet one

Modern video compression is variable rather than fixed, and that surprises people who expect storage to be predictable. A static scene at night with nothing moving compresses extremely efficiently, because frame after frame is nearly identical. A daytime scene with machinery moving, dust blowing, crews walking and a flag snapping in the wind contains far more change, and change is what video compression spends bits on.

The consequence is that the same hardware on the same site holds a different number of days depending on how busy the site is. A demolition week with plant moving constantly consumes storage faster than the quiet fortnight before mobilisation. Weather does it too: heavy rain and moving vegetation both generate visual change that costs storage without containing anything anyone wants to watch.

This is worth knowing for a practical reason. The period during which you most want deep history — an active, busy, high-value phase of the project — is precisely the period during which the continuous record is aging fastest. If your instinct is to rely on going back later during the busiest month of the job, that is the moment the instinct is least reliable.

It is also the reason detection zones and schedules matter to retention and not just to alert noise. A system that records purposefully rather than indiscriminately gets more useful history out of the same storage, which is one of several reasons the zone configuration done at setup is worth taking seriously rather than accepting as a default.

Local recording, and what survives a bad night

Where the footage physically lives determines what survives the failures that actually happen on jobsites. On SiteFortress360 units the recording is local, on storage inside the unit, with alerts and live view delivered over the included LTE connection. That architecture is chosen for a specific reason: connectivity on a jobsite is the least reliable component in the entire system, and a cloud-only recorder stops being a recorder the moment the cell signal drops behind a new concrete pour.

With local recording, a connectivity outage costs you live view and notifications while it lasts. It does not cost you the recording. The unit keeps recording throughout and the footage is there when the link returns, which is the difference between an inconvenient night and a night with no evidence of the one event you needed.

The honest counterpart is that local storage has a failure mode cloud storage does not: if the unit itself is destroyed or taken, the footage on it goes too. That is why the unit is GPS geofenced and tamper monitored, why movement of the unit generates the loudest alert the system produces, and why anything that matters should be exported rather than left on the device. Both architectures have a bad day; the local one has a rarer bad day on a jobsite.

Getting footage out, and what police and carriers need

When an event matters, the goal is to move it off the retention clock and into a file somebody can use. What investigators and carriers consistently need is narrower than most people assume, and knowing it in advance turns a stressful morning into a ten-minute job. They need the clip itself in a format that plays without proprietary software. They need accurate date and time, which is why system clock accuracy is not a pedantic detail. They need enough context before and after the event to establish sequence rather than a tight cut of the moment itself. And they need to know which camera produced it and where that camera was pointing.

Export more than you think you need. A clip that starts two minutes before the person appears and runs two minutes past their exit is far more useful than a thirty-second excerpt, because sequence is frequently the question: which direction they came from, whether a vehicle waited, whether they returned. Storage on your own laptop is free and the original is on a clock.

If a theft or an incident has occurred, the practical order is: identify the event, export generously with time context, note the camera and its position, and only then start making phone calls. A police report filed with footage attached is a materially different document from one filed with a description, and the same is true of a first notice of loss to a carrier.

It is worth setting one thing up on day one rather than at the moment of crisis: know who on your team can retrieve and export footage, and have them do it once while nothing is wrong. The first export should not happen at seven in the morning after a break-in, with the person who knows how on annual leave.

Frequently asked questions