Check what cameras record when the internet goes down

Quick answer: Test internet loss against the actual recording architecture, with power and the intended local network left in their agreed state. Check newly captured footage, local access, remote access, and recovery separately. Neither cloud-managed nor local-recorder branding proves what every installed configuration will do during an outage.

An owner checking a camera from a phone may see it disappear when the internet fails. That screen does not establish whether the camera has stopped recording or whether only the remote path is unavailable. The distinction matters when someone later needs the footage from that period.

An outage demonstration should answer the business's real questions: what continues, what cannot be used immediately, and how the recording becomes available afterward. Start with the proposed camera-to-storage path so the test exercises the condition the business actually wants to understand.

Define internet loss without combining unrelated failures

Specify the scenario before arranging the test. Loss of the site's internet service is different from a powered-off PoE switch, failed recorder, disconnected camera cable, or unavailable management application. Combining several failures at once makes the result harder to interpret.

Have the responsible network team select a supported test method and approved work period. Confirm which business services share the connection and who needs notice. A camera acceptance exercise should not unexpectedly interrupt unrelated operations.

Record the intended state of power and local connectivity during the test. If the camera loses power as well as internet access, the result does not isolate the internet dependency. Similarly, disabling a feature inside the management platform may have a different effect from the modeled carrier interruption.

Use the outage scenario as a defined question. A short test can establish what happened under those conditions; it should not become a claim that the system survives every network fault or every outage duration.

Draw where new footage is stored

Identify the recording destination for each camera type in the proposal. Some designs store video on the camera, some send it to a recorder on the same network, and others use a remote destination. Optional backups or archives add further paths that should be shown separately.

Verkada's network-loss documentation describes continued onboard recording while the camera has power. It also notes that outage footage can take time to become accessible after reconnection. That is different from promising immediate remote access throughout an interruption.

UniFi Protect Teleport Adoption supports specified configurations that record across the internet to another site's gateway or NVR. The page describes local outage recording for cameras with edge-recording capability. Do not apply that capability to every camera or assume every Protect installation records only within its own site.

The UniFi Protect versus Verkada guide helps compare operating models. For acceptance, the exact installed route and supported features matter more than the broad platform category.

State what the business needs during the interruption

Decide whether the requirement is continued capture, immediate onsite review, remote viewing, remote export, or some combination. These tasks can have different dependencies. A design might retain footage for later review while a remote manager cannot see current activity during the outage.

Ask how authorized staff at the site would retrieve footage under the proposed condition. Include the necessary device, network connection, account, and application. A theoretical local access option is less useful if nobody at the location has the approved means or knowledge to use it.

Keep important limitations in the proposal. If a task requires an active internet connection, state that directly and consider whether backup connectivity belongs in the project. Do not hide the dependency behind an optimistic description of offline recording.

For a hypothetical storage facility, the owner may accept delayed remote review but require the entry view to continue recording locally. Another operation may require a live offsite response. Those are different requirements and should produce different acceptance criteria.

Capture an identifiable event before, during, and after

Stage benign activity that can be recognized in playback. Use the same camera identifiers and reference times across the exercise. The activity should occur during the interruption, not just before it, so the later review can establish whether new footage was captured.

A focused observation plan can include:

• Confirm the approved recording settings and destination beforehand.
• Stage recognizable activity before and during the interruption.
• Check the required onsite and offsite access methods separately.
• Restore the connection through the approved procedure.
• Retrieve the staged interval and inspect continuity and quality.

Do not infer recording success solely from a status light or a cached image. Those indicators can help the technical team, but the buyer's acceptance evidence should include the resulting footage. Check that the retrieved interval corresponds to the actual test event.

If the system uses detection-only recording, make the staged activity appropriate to the approved detection configuration. An absent clip could otherwise reflect the recording policy rather than the internet interruption. Keep those variables visible so the result can be diagnosed accurately.

Check the recovery interval as carefully as the outage

Once connectivity returns, observe the system until the relevant footage and functions reach the expected state. A camera appearing online does not by itself prove that every retained interval is immediately searchable or available for export.

Ask the supplier to explain any synchronization or upload process. The amount of retained material, connection capacity, recording settings, and platform behavior can affect recovery. Avoid promising a fixed recovery time without an established basis for the selected configuration.

Inspect both the outage footage and current recording. A system that retrieves the old interval but has not resumed the intended ongoing behavior still needs attention. Review any unresolved alerts and confirm which team will investigate them.

Keep temporary test changes under control. If the exercise required an approved policy adjustment, return it to the intended configuration and verify that state. The final result should describe the working system after recovery, not merely the moment when one test clip appeared.

Evaluate backup connectivity against the actual camera workload

A secondary internet service may preserve some remote functions or support a remote recording path. Determine which traffic it needs to carry and how the network chooses that path. Do not size it from the number of cameras alone.

Continuous remote recording, occasional live viewing, metadata, and recovery uploads are different workloads. Identify what the platform sends during normal operation and during recovery. The service's upload capacity and usage terms should be evaluated against those actual tasks.

The business internet failover guide can help coordinate the network side. A working gateway transition does not prove every camera function remains uninterrupted; repeat the relevant camera workflow under the approved backup arrangement.

Also preserve the power distinction. A second carrier does not keep an unpowered camera, switch, or recorder running. The outage plan should explain which dependency each investment addresses and what remains outside the accepted scope.

Turn the result into usable staff instructions

Write the operational conclusion in plain language. Identify which recording continues, which review methods remain available, and what staff should do when remote viewing is unavailable. Avoid a blanket statement that the cameras work offline if that phrase conceals important differences.

Provide a reachable support path and the observations staff should report. Site name, approximate time, affected views, and whether local equipment has power can be useful starting information. Keep technical recovery steps with authorized personnel rather than encouraging broad resets.

Repeat relevant checks after material architecture changes. Moving a recorder, adopting a camera remotely, changing network policy, or enabling another storage feature can alter the outage behavior. The original acceptance result applies to the configuration that was tested.

For several locations, retain the site-specific outcome even when the platform is standardized. Internet paths, recording destinations, local access arrangements, and backup power can differ. A common checklist should reveal those differences, not erase them.

The takeaway

An internet outage is a test of the recording and access paths the project actually uses. Separate continued capture from immediate viewing and later retrieval. Verify the newly recorded interval and the recovered operating state instead of relying on a platform label or a dashboard indicator.

That evidence makes the proposal easier to judge and the system easier to operate. The business can decide whether delayed access is acceptable, whether backup connectivity is justified, and which staff instructions are needed when the ordinary remote view disappears.

Define camera outage acceptance

Bring the site connections, proposed recording destinations, and required review tasks to BlueHouse's security camera installation service.

FAQ

Does losing remote viewing mean recording stopped? Not necessarily. The remote access path may fail while recording continues elsewhere. Verify the configured architecture and inspect footage captured during an approved test interval.

Does UniFi Protect always record within the camera's site? No. Supported Teleport Adoption configurations can record across the internet to another site's compatible destination. Confirm the exact devices, software, network requirements, and outage behavior in the proposal.

Will outage footage appear immediately after reconnection? Do not assume so. Some systems need synchronization or upload time. Test the relevant workflow and document what was observed without turning a short sample into a universal recovery guarantee.

Should we test internet and power loss together? Start with clearly defined scenarios so the result is interpretable. The responsible teams can plan additional combined tests when appropriate, using approved procedures and the actual continuity requirements.