Recording Strategies: Continuous, Motion, Event, and Scheduled

Why this matters

In our companion article on surveillance storage and the retention math, one term in the storage formula — the recording factor, the fraction of the day a camera actually writes to disk — was flagged as the biggest lever you control. This article is that lever in full. It is for the security integrator, product manager, or operations lead who has to decide how each camera records, sign off on a storage quote, or explain to a client why "just record everything" is rarely the right answer. Get the recording strategy right and you cut the storage bill, the review time, and the privacy exposure all at once. Get it wrong and you either drown in footage nobody watches or miss the ten seconds that mattered. No special technical background is needed; every trade-off is explained in plain terms with the numbers shown.

The recording factor: one number from the storage equation

Start with the formula that governs every surveillance storage estimate. The software that ingests and records many camera streams — the Video Management System, or VMS — turns each camera's data rate into a pile of files, and the size of that pile is one multiplication:

Storage (GB) = bitrate (Mbps) × 10.8 × cameras × retention days × recording factor

We walk through every term of that equation in the retention-math article; here only the last term matters. The recording factor is the fraction of each day a camera writes video. A camera recording around the clock has a factor of 1.0. A camera that records only the four hours a day something actually happens has a factor near 0.17 — roughly a sixth of the storage. Resolution, frame rate, and codec set how big each recorded hour is; the recording factor sets how many hours you record at all. That is what a recording strategy chooses, and it is why the same camera can need six terabytes a month or six hundred gigabytes depending on nothing but how it is told to record.

There are four ways to make that choice. The rest of this article is each one, what it costs, what it risks, and how to combine them.

Figure 1. The four recording modes over one day — the shaded segments are what gets written to disk.

Mode 1 — Continuous recording: the safe, expensive default

Continuous recording — sometimes sold as 24/7 recording or CVR (Continuous Video Recording) — writes every frame, all day, every day. Its recording factor is 1.0, and it is the only mode that guarantees you have footage of any moment, whether or not anything tripped a sensor. If a dispute later hinges on what happened at 3:47 a.m. in an empty corridor, continuous recording has it.

That guarantee is also its cost. A camera watching a loading dock that sees activity two hours a day still writes twenty-two hours of empty footage. Using the worked example from the retention article — a 4-megapixel camera in the H.265 codec at a typical 2 Mbps — continuous recording produces:

2 Mbps × 10.8 = 21.6 GB per camera per day

Across forty such cameras kept for thirty days that is about 26 terabytes of raw video, most of it showing nothing. Continuous recording is the right choice where a gap is unacceptable — entrances, cash handling, gaming tables, custody areas, anywhere a missing second is a liability — and the wrong choice as a blanket default for every camera on the site. The mistake is not using it; the mistake is using it everywhere.

Mode 2 — Motion-triggered recording: record when the scene changes

Motion-triggered recording writes only while the camera detects change in its field of view. When the scene is still, it records nothing; when something moves, it starts. On a camera that watches a mostly static scene, that drops the recording factor sharply — industry figures put the saving at 50–80% versus continuous, and a common rule of thumb is that motion-only recording divides storage roughly by three.

How the camera decides "something moved" matters, and it is where most motion-recording disappointment comes from. The oldest and still most common method is pixel-change detection: the camera compares each frame to the last and triggers when enough pixels change. It is cheap and universal, and it cannot tell a person from a passing cloud. Rain, headlights sweeping a wall, shadows, swaying trees, snow, insects on the lens, and a light switching on all look like "motion" and all start recording — so a camera you expected to record two hours a day records twelve, and the storage saving you budgeted for evaporates. Worse, pixel detection can also under-record: a slow, low-contrast intruder moving at the edge of the frame may never cross the threshold.

The modern fix is AI object-based detection, the 2026 default on serious cameras. Instead of counting changed pixels, the camera runs a lightweight neural network that classifies what moved — person, vehicle, animal — and records only for the classes you care about. Because trees, shadows, rain, and animals no longer trigger it, object-based recording cuts false triggers by a reported 90–95% compared with pixel motion, turning a hundred nuisance recordings into five or ten meaningful ones. We do not re-derive how that detection model works here; the object detection and classification article in our AI for Video Engineering section owns the model internals. For recording strategy, the point is simple: object-based motion both saves more storage and floods you with fewer junk clips than pixel motion, and on a 2026 camera it is usually worth turning on.

Mode 3 — Event and analytics-triggered recording: record when a rule fires

Event-triggered recording — also called analytics-triggered recording — is motion recording's precise cousin. Instead of recording on any qualifying movement, it records only when a specific rule fires: a line is crossed, a defined zone is entered, a person loiters past a set time, a license plate matches a watch list, a door-contact or alarm input closes, or an analytic flags an object of interest. It is the most selective of the four modes, and on a camera with a tight rule it can push the recording factor into single-digit percentages.

The rules themselves come from the analytics layer, which we cover in the behavioral analytics article — line crossing, intrusion zones, loitering, and the rest. What matters for recording is that the analytic produces an event, and the recording engine listens for it. When the event arrives, recording starts; when the condition clears, it stops. This is also the mode that integrates with the rest of a security system: an access-control denial, a fire-panel signal, or an operator's panic button can all be the "event" that starts cameras recording at full rate.

Event recording earns its keep on cameras where almost nothing should ever happen — a fenced perimeter at night, a restricted room, a secure cabinet. There it records the rare real incident and almost nothing else. Its weakness is the mirror of its strength: a clip exists only if the rule fired, so a poorly drawn zone or an untuned threshold means a real incident is simply never recorded. Event recording rewards careful setup and punishes "set it and forget it."

Mode 4 — Scheduled recording: record on a clock

Scheduled recording ties the recording mode to the time of day and day of week. The classic pattern is continuous recording during business hours and motion or event recording overnight and on weekends — or no recording at all in zones that are genuinely irrelevant when the building is empty. It is less about reacting to the scene and more about matching recording to when footage has value.

Scheduling is rarely used alone; it is a wrapper around the other three. A retail floor might record continuously from 8 a.m. to 9 p.m. and switch to AI-event recording overnight; a school might record continuously on weekdays and motion-only at weekends. Done well, scheduling captures the predictable busy window in full and lets the quiet hours collapse to a fraction of the data. Its risk is the obvious one: an incident that happens outside the "interesting" window, in a mode you set to off or to a tight trigger, is recorded thinly or not at all — so the schedule has to be drawn around the real risk, not just the opening hours.

Here are the four modes side by side. The storage factor is illustrative — the real number depends on how busy the scene is and how the triggers are tuned.

Recording mode	What starts it	Typical storage vs continuous	What you risk missing	Best for
Continuous (24/7)	Nothing — always on	100% (baseline)	Nothing	Entrances, tills, custody, gaming
Motion-triggered	Scene change (pixel or AI object)	~20–50%	Slow/low-contrast subjects; over-records on weather	General-area cameras
Event / analytics	A specific rule or external signal	~5–25%	Anything the rule didn't cover	Perimeters, restricted zones
Scheduled	Clock / calendar	Depends on hours set	Incidents outside the window	Predictable business hours

Figure 2. The four modes compared — trigger, storage cost, blind spot, and best use.

The pre-event buffer: how triggered recording stops missing the run-up

Every mode except continuous shares one flaw, and it is the single most important thing to understand about triggered recording: a trigger fires after the interesting thing has already started. Motion is detected a moment after movement begins; an analytic event is raised after the person has entered the zone. If recording starts only when the trigger fires, you capture the incident but lose its run-up — the approach, the face before it turned away, the vehicle before it stopped. In an investigation, the run-up is often the part that matters.

The fix is the pre-event buffer, also called pre-record or pre-roll. The camera continuously holds the last few seconds of video in a rolling memory buffer even when it is not recording to disk. When a trigger fires, it writes that buffered run-up plus the live footage, so the saved clip begins seconds before the trigger. A matching post-event buffer (post-roll) keeps recording for a set time after the condition clears, so you do not lose the aftermath. Typical settings run a few seconds to about 30 seconds on each side; when the pre-buffer is held in RAM it is often capped around 15 seconds, with longer pre-buffers written to the storage medium. Milestone's XProtect, a widely used VMS, documents exactly this in-memory pre-buffering behavior.

[ pre-buffer: 5–15 s ] → TRIGGER → [ event recorded ] → [ post-buffer: 10–30 s ]
        held in memory                live to disk            keeps the aftermath

The practical rule: any camera on motion or event recording should have a pre-event buffer of at least five seconds, and more like ten to fifteen on perimeters and approaches. A triggered-recording system without a pre-buffer is a system that reliably records the second half of every incident.

Figure 3. The pre-event buffer saves the run-up; the post-event buffer saves the aftermath.

Common mistake: trusting motion recording to be cheap and complete. Teams often switch every camera to motion recording, see the storage estimate drop, and assume the job is done. Two things then go wrong. First, on outdoor or busy scenes, pixel-based motion over-triggers on rain, headlights, and foliage, so the real storage lands far above the estimate and the disks fill early. Second, with no pre-buffer and a slightly slow trigger, the saved clips keep starting late and missing the approach. The cameras look like they are saving money and capturing events, while quietly doing neither well. The fix is object-based triggers to stop the false starts, a pre-buffer to catch the run-up, and a real test — walk the site, trip each camera, and watch the clips — before trusting the strategy.

Combining the modes: the strategy that actually ships

No real system picks one mode for every camera. The strategy that survives a budget review assigns a mode camera by camera, based on what each camera watches and what a gap there would cost. A workable default for a mixed site:

• Continuous on the handful of cameras where a missing second is unacceptable — main entrances, points of sale, cash rooms, custody or gaming areas.
• AI-event or motion with a pre-buffer on general-area and perimeter cameras, where the rare real event matters and the empty hours do not.
• Scheduled as the wrapper — full recording during the predictable busy window, tighter triggers when the site is closed.

Walk the numbers on the forty-camera example. All continuous, it is about 26 TB for thirty days. Now suppose eight cameras stay continuous and the other thirty-two move to AI-event recording at an average recording factor of about 0.25 (a quarter of the day, generous for a perimeter):

 8 cameras continuous:  8 × 21.6 GB × 30 days  ≈  5.2 TB
32 cameras at 0.25:    32 × 21.6 × 0.25 × 30   ≈  5.2 TB
                                        total   ≈ 10.4 TB

That is about 10 TB instead of 26 TB — roughly a 60% cut at the site level, while the eight cameras that matter most still record every frame. Push further on a single quiet camera and the saving is larger still: a perimeter camera on a tight AI-event trigger might record well under a tenth of the day, taking its daily storage from 21.6 GB toward 2 GB — close to an order-of-magnitude reduction on that one camera. The blended site saving is more modest than the best-case single camera because the continuous cameras dominate the total — which is exactly why the strategy is to keep that continuous set small and deliberate.

Figure 4. Daily storage per camera by mode — the mode is the lever, and tight event recording is roughly a tenth of continuous on a quiet scene.

Where the standards fit: ONVIF Profile G and Profile M

Recording modes are mostly configured in the VMS, but two ONVIF profiles decide whether that configuration survives a change of vendor. ONVIF is the common language that lets cameras and recording software from different makers work together; its profiles split that language by job.

ONVIF Profile G is the open standard for recording and retrieval. Its specification — current version 1.1, published October 2025 — defines how an ONVIF client (your VMS) controls recording on an ONVIF device (a camera, encoder, or network video recorder) and how it searches and replays what was stored. Concretely, Profile G standardizes recording jobs: a conformant client can create and delete recording jobs (CreateRecordingJob, DeleteRecordingJob), read their state, and crucially change a job's mode with the SetRecordingJobMode operation — the standardized hook that lets a VMS switch a recording job between active and idle. It also standardizes event search (FindEvents), so the clips that triggered recording can be found again across vendors.

Here is the boundary that keeps a buyer out of trouble. Profile G standardizes the control and retrieval interface — start, stop, manage the job, search the result. It does not standardize the trigger logic: what counts as motion, how a schedule is defined, how long the pre- and post-buffers run, and how sensitive a zone is are configured on the device or in the VMS, and the richer ones often need the vendor's own software. Remember the surveillance rule from our ONVIF explainer: ONVIF guarantees a baseline both devices conform to, not full feature parity. For the commercial overview of how the profiles map to real products, Fora Soft's guide to ONVIF profiles in security systems is the companion read.

The analytics that drive event-triggered recording surface through ONVIF Profile M, the metadata-and-analytics profile. When a camera's analytic raises an event — an object classified, a line crossed — Profile M is how that event travels in a standardized form to the VMS, which can then start a Profile G recording job. We cover that handoff in detail in events, metadata, and the ONVIF analytics interface. The two profiles together — M to carry the event, G to record on it — are the standards spine under analytics-triggered recording.

Figure 5. ONVIF Profile G standardizes recording control and retrieval; Profile M carries the analytics event — but the trigger logic, schedule, and buffers stay device- and VMS-side.

Recording mode is also a privacy lever

Choosing a recording mode is usually framed as a storage decision, but in privacy-regulated regions it is also a compliance one — and the two pull the same way. Under the EU's General Data Protection Regulation (GDPR, Regulation (EU) 2016/679), recognizable video of people is personal data, and Article 5(1)(c), the data-minimisation principle, requires that the data collected be "adequate, relevant and limited to what is necessary." Recording only when and where something relevant can happen is data minimisation in action. (This is engineering guidance, not legal advice — confirm the specifics for your jurisdiction with qualified counsel.)

The European Data Protection Board's Guidelines 3/2019 on processing of personal data through video devices make the link explicit. They state that recording "should also not take place at times of day or in areas which are not necessary or relevant for the purpose," and give the worked example that a controller should consider whether "only operating the cameras at night" would meet the goal. That is a regulator describing scheduled and zone-limited recording as a privacy-preserving design, not just a storage tactic. A camera set to record only the perimeter, only after hours, on object-based triggers, collects less personal data than one grinding through 24 hours of an occupied office — and is easier to justify. The retention side of the same principle — how long to keep what you did record — lives in our retention policy article and is governed by the storage-limitation rule in GDPR Article 5(1)(e). The takeaway: the recording strategy that is cheapest is often also the one that collects the least, and privacy law rewards both.

Where Fora Soft fits in

Recording strategy is one of those design choices that looks trivial in a settings menu and decides, months later, whether a system holds the footage that matters without drowning in the footage that does not. Fora Soft has built video streaming, real-time video, and computer-vision systems since 2005 — more than 625 shipped projects — and surveillance sits at the intersection of all three. When we build or customize a VMS, we wire recording mode per camera rather than per site: AI-object event recording where pixel motion would over-trigger, pre- and post-event buffers sized to the camera's job, schedules drawn around real risk, and the whole thing tied to a retention policy so storage and compliance move together. The accuracy-vs-performance habit applies here too — we test the strategy by tripping every camera and watching the clips, because a recording mode that looks right in the configuration and misses the approach on the day of an incident is not a strategy, it is a liability.

What to read next

• How surveillance storage works: the retention math
• Storage tiers: hot, warm, cold, and archive
• Retention policy: how long to keep footage, and why

Download the recording-strategy decision guide (PDF) — the four modes at a glance, the pre/post-buffer settings, the combining recipe, and a blank per-camera mode-assignment worksheet.

Call to action

• Talk to a surveillance engineer — book a 30-minute scoping call to talk through your cctv recording modes plan.
• See our case studies — 250+ shipped projects across video streaming, WebRTC, OTT, telemedicine, e-learning, surveillance, and AR/VR.
• Download the Recording-Strategy Decision Guide — One-page printable guide: the four recording modes at a glance (trigger, storage vs continuous, blind spot, best for), the pre/post-event buffer settings, the combine-by-camera recipe, the worked 40-camera storage example, and a blank….

References

1. ONVIF Profile G Specification, Version 1.1 (October 2025), ONVIF. The open standard for recording and retrieval: recording-job control (CreateRecordingJob, DeleteRecordingJob, GetRecordingJobs), recording-job state and mode (GetRecordingJobState, SetRecordingJobMode), the RecordingJobStateChange event, and recording/event search (FindRecordings, FindEvents). Read directly from the specification PDF. Tier 1. https://www.onvif.org/wp-content/uploads/2025/11/ONVIF-Profile-G-Specification-v1-1.pdf (accessed 2026-06-09)
2. ONVIF Profile M (metadata and analytics), ONVIF. The profile that carries analytics events and metadata — the standardized path by which an analytic event (object, line crossing) reaches the VMS to trigger event-based recording. Tier 1. https://www.onvif.org/profiles/profile-m/ (accessed 2026-06-09)
3. GDPR — Regulation (EU) 2016/679, Article 5(1)(c) (data minimisation), European Union (EUR-Lex). Personal data must be "adequate, relevant and limited to what is necessary" — the principle that makes a tighter recording mode a compliance act as well as a storage saving. Tier 1. https://eur-lex.europa.eu/eli/reg/2016/679/oj (accessed 2026-06-09)
4. EDPB Guidelines 3/2019 on processing of personal data through video devices, European Data Protection Board. Recording "should also not take place at times of day or in areas which are not necessary or relevant for the purpose"; the controller should consider whether "only operating the cameras at night" meets the goal — the regulator framing scheduled/zone-limited recording as data minimisation. Tier 1. https://www.edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_201903_video_devices.pdf (accessed 2026-06-09)
5. EN IEC 62676-4:2025: Video surveillance systems for use in security applications — Part 4: Application guidelines, IEC / CENELEC. Practical guidance for planning recording and storage, including recording-mode selection; current 2025 edition. Tier 1. https://webstore.iec.ch/publication/68479 (accessed 2026-06-09)
6. Pre-buffering and storage of recordings (explained), Milestone Systems (XProtect VMS documentation). How a VMS holds a rolling pre-event buffer in memory (capped around 15 seconds in RAM) and saves it with the triggered recording. Tier 3. https://doc.milestonesys.com/latest/en-US/standard_features/sf_mc/sf_mcnodes/sf_3devices/mc_prebufferingexplained_devices.htm (accessed 2026-06-09)
7. Do CCTV Cameras Record All the Time or Only When Motion Is Detected? (2026 Guide), Backstreet Surveillance. Motion-triggered recording cuts storage roughly 50–80% on static scenes; the hybrid (continuous on critical cameras, motion elsewhere) recommendation. Tier 5. https://www.backstreet-surveillance.com/blog/post/do-cctv-cameras-record-all-the-time-or-only-when-motion-is-detected (accessed 2026-06-09)
8. How Much Storage Does a Security Camera Need?, Security Camera King. Motion-only recording dropping four cameras from continuous to ~30–50 GB/camera/day, an ~80% reduction; per-camera continuous baselines. Tier 5. https://www.securitycameraking.com/securitynews/how-much-storage-does-a-security-camera-need/ (accessed 2026-06-09)
9. AI vs. Motion Sensors: The End of the "False Alarm" Era in 2026, Bay Alarm. AI object-classification recording reduces false triggers by roughly 90–95% versus pixel-change motion — turning 100+ nuisance events into 5–10 meaningful ones. Tier 5. https://www.bayalarm.com/blog/ai-motion-sensors-false-alarm-era/ (accessed 2026-06-09)
10. Recording Variables (Anti-Dither, Pre-Record, Pack Duration) — A Rundown, IP Cam Talk. How pre-record, post-record, and anti-dither settings work on common NVRs; why a pre-buffer is needed so a triggered clip captures the run-up. Tier 6. https://ipcamtalk.com/threads/recording-variables-anti-dither-pre-record-pack-duration-etc-providing-a-rundown-of-what-they-others-do-how-they-work.47056/ (accessed 2026-06-09)

Where sources disagreed, the official standard or law was followed. Popular articles quote single motion-recording savings numbers ("cuts storage by X%") as if universal; the controlling reality is that the saving depends entirely on scene activity and trigger type, so the article frames the figures as ranges and shows the arithmetic. On the standards boundary, listicles imply "ONVIF cameras just record the same everywhere"; the Profile G specification establishes that ONVIF standardizes the recording-control and retrieval interface, not the trigger logic, schedule, or buffer lengths — so those are framed as device/VMS-side.