Motion-Triggered vs Continuous Recording: How Each Affects Network Bandwidth
How motion-triggered recording changes real-time network bandwidth patterns compared to continuous CCTV recording, and why a motion-heavy network can spike well above its average load.
Published July 15, 2026
Continuous recording produces a flat, predictable network load; motion-triggered recording produces a genuinely different bandwidth pattern — low average usage punctuated by real spikes — and sizing a network for the wrong pattern is a distinct mistake from getting the raw bitrate numbers wrong.
Two genuinely different bandwidth patterns
Flat, constant network load — a camera transmits its full bitrate essentially all the time, regardless of activity.
Low baseline (often just a low-bitrate keep-alive stream or nothing), with real bandwidth spikes exactly when motion is detected.
This distinction is specifically about the shape of bandwidth usage over time, not just the average — continuous recording, as the Network Bandwidth Calculator’s sum-of-bitrates model directly assumes, produces a genuinely flat, sustained load equal to the sum of all camera bitrates essentially all the time. Motion-triggered recording instead produces a much lower average load punctuated by real spikes exactly when and where motion is actually detected — a fundamentally different pattern that the same flat sum-of-bitrates model doesn’t accurately represent on its own.
Why average bandwidth isn’t the right sizing number for motion-triggered systems
A network sized only for a motion-triggered system’s typical low average load risks a real problem during exactly the scenario that matters most: a genuine security event, a storm, or any circumstance that triggers motion across many cameras simultaneously. In that scenario, a motion-triggered system’s actual instantaneous bandwidth need converges toward the same figure a fully continuous system would need — the same sum-of-all-camera-bitrates ceiling — precisely at the moment reliable video matters most, which is exactly the wrong time for a network to become bandwidth-constrained.
This is sometimes described as the same underlying risk that motion-triggered recording's storage savings trade against — a system optimized around typical, low-activity average usage can be caught short exactly during the atypical, high-activity events that CCTV exists to capture in the first place, whether the resource being constrained is storage or, as covered here, real-time network bandwidth.
A worked illustration
Network Sizing Target = Sum of All Bitrates (worst-case), NOT typical average load
The same conservative-ceiling logic that applies to VBR bitrate mode applies equally to motion-triggered recording's bandwidth pattern.
For a 16-camera motion-triggered installation at 4096 Kbps each, typical day-to-day average bandwidth might genuinely be a small fraction of the full 65.54 Mbps sum-of-bitrates figure — but sizing the network only for that typical average, rather than the full sum, leaves the network under-provisioned for exactly the multi-camera simultaneous-motion scenario that represents genuine risk.
Why this parallels the CBR/VBR bitrate mode question
This bandwidth-pattern issue is conceptually the same underlying caution covered in CBR versus VBR bitrate mode — in both cases, an average or typical figure understates the real worst-case bandwidth requirement, and reliable network sizing means planning against that worst case, not the more comfortable-looking average. Motion-triggered recording adds a second, independent layer of this same “average versus worst-case” gap on top of whatever gap already exists from bitrate mode alone.
When motion-triggered’s average-load savings are still genuinely useful
None of this means motion-triggered recording’s bandwidth savings are illusory — for network links with substantial spare capacity beyond the full worst-case sum (a genuinely over-provisioned network, or one shared with other traffic that has its own separate slack), motion-triggered recording’s typically lower real-world average usage is a genuine, practical benefit most of the time. The caution here is specifically about sizing decisions — the network needs to be built to handle the worst case reliably, even if it spends most of its time well under that ceiling thanks to motion-triggered recording’s genuine average-load reduction.
A sizing checklist for motion-triggered systems
| Question | Why it matters |
|---|---|
| What’s the full sum-of-bitrates figure if every camera triggered simultaneously? | This is the real network sizing ceiling, not the typical average |
| How correlated is motion across cameras in a real event? | A single building-wide event (storm, security incident) can trigger many cameras at once |
| Is the network shared with other traffic? | Shared links need the full worst-case CCTV figure plus other traffic’s own requirements |
| What’s genuinely acceptable if a spike is under-provisioned? | Dropped frames or recording gaps during exactly the events that matter most |
Sizing correctly for your own installation
The Network Bandwidth Calculator’s sum-of-bitrates output represents the reliable worst-case figure appropriate for network sizing, regardless of whether your installation uses continuous or motion-triggered recording — the practical difference motion-triggered recording makes is in typical real-world average utilization, not in the ceiling a network genuinely needs to be able to handle when it matters.
FAQ
Does motion-triggered recording reduce the network bandwidth I need to provision? Not the reliable sizing ceiling — that should still be based on the full sum of all camera bitrates, since simultaneous motion across many cameras can approach that same full figure during genuine events.
Is motion-triggered recording’s bandwidth savings real, or a false economy? The average real-world savings are genuine and meaningful for typical day-to-day usage — the caution is specifically about not using that lower average as the network sizing target, since worst-case simultaneous-motion scenarios still need full capacity.
How correlated is motion across multiple cameras in practice? Highly variable by installation, but many real trigger events (storms, security incidents, a building-wide alarm) genuinely do trigger motion across multiple cameras simultaneously, which is exactly the scenario worst-case sizing needs to account for.
Should I size differently for motion-triggered versus continuous recording? The network bandwidth ceiling should be sized the same way for both — the full sum of camera bitrates — since motion-triggered recording’s real difference is in average utilization, not the worst-case requirement.
Does this affect storage sizing the same way it affects network bandwidth? The underlying principle (average isn’t the same as worst-case) is similar, though storage sizing calculations typically already build in realistic average-usage assumptions for motion-triggered systems in a way that’s appropriate for storage specifically — network bandwidth sizing is the context where the worst-case-ceiling caution matters most directly.
Is there a way to reduce the real risk of a simultaneous-motion bandwidth spike? Adequate headroom beyond even the full sum-of-bitrates figure, combined with sizing for the full worst case rather than a typical average, together provide the most reliable protection against this specific risk.
Cameras also commonly run main and sub-streams simultaneously, which adds a second bandwidth consideration alongside recording mode.