Cameras

IP camera keeps going offline

Find why a camera drops — PoE budget, DHCP lease/IP conflicts, cable voltage drop, or a VLAN firewall change.

Problem summary

A camera dropping offline is usually power, addressing, or cabling — not firmware. Several cameras dropping together points at the switch's PoE budget; an hourly drop is a short DHCP lease renewing; one camera rebooting points at its cable run; and 'offline' only in the NVR can be an inter-VLAN firewall change.

Operator snapshotEvidence first

First proof

Note whether ONE camera or SEVERAL drop, and any timing pattern.

Screen to open

ping -t <camera-ip> (Windows) / ping <camera-ip> (Linux/mac)

Expected signal

A single camera, or several together, with or without a clock-like pattern.

Stop boundary

Don't reset the camera for what is a firewall/reachability issue.

Layer path

1An IP camera dropping offline is usually power, addressing, or cabling — not the camera firmware. Work PoE budget, IP/DHCP, and the physical link before reflashing or replacing it.

2A camera that goes offline 'every hour on the hour' is the signature of a too-short DHCP lease renewing — set a reservation or lengthen the lease.

3Intermittent drops across several cameras point at the switch's PoE budget or a marginal uplink; a single camera points at its cable/run or that port.

4On an isolated camera VLAN, a firewall change can look like the camera 'going offline' to the NVR when it's really reachability.

Runbook

Step-by-step runbook

Start here. Do each check in order, compare it to the expected result, and stop when the evidence explains the failure or the safe stop point applies.

Characterize the drop pattern

Check: Note one-vs-many cameras and any timing (e.g. hourly, nightly).

Expected result: You know which layer to investigate.

If not: Many+nightly → PoE; periodic → DHCP; one → cable; NVR-only → firewall.

Check PoE budget

Check: Compare total camera draw (with IR/heaters) to the switch budget at 80%.

Expected result: Usable budget exceeds draw with headroom.

If not: If not, offload cameras; size with /tools/poe-budget-calculator.

Stabilize addressing

Check: Set DHCP reservations (or static IPs), lengthen the lease, and clear conflicts.

Expected result: Cameras keep stable IPs and stop dropping on renewal.

If not: An IP conflict will keep knocking a camera off until resolved.

Fix the physical run

Check: Inspect/re-terminate the affected cable; verify delivered PoE at distance.

Expected result: The run is solid and the camera stops browning out.

If not: Long runs near 100 m may need a higher PoE class or a shorter path.

Rule out the VLAN firewall

Check: If the camera pings but the NVR shows it offline, allow the NVR→camera path.

Expected result: The NVR reaches the camera while it stays internet-isolated.

If not: Don't factory-reset a camera for what is a firewall/reachability problem.

Decision tree

If: Several cameras drop together, worse at night.

Then: PoE budget exceeded (IR/heaters raise draw after dark).

Action: Size with the PoE budget calculator; split load across switches/injectors.

If: Camera offline on a clock-like interval.

Then: Short DHCP lease renewing or an IP conflict.

Action: Set a DHCP reservation, lengthen the lease, and clear duplicate IPs.

If: One camera on one run keeps rebooting.

Then: Cable distance/damage/termination (voltage drop).

Action: Re-terminate/replace/shorten the run; confirm delivered PoE at that distance.

If: Camera reachable locally but 'offline' in the NVR.

Then: Inter-VLAN firewall blocking the NVR→camera path.

Action: Allow the NVR to reach the camera's ports across the VLAN.

Safe stop: Don't reset the camera for what is a firewall/reachability issue.

Evidence

Evidence table

Symptom	Evidence to collect	Likely layer	Next action
Multiple cameras drop, especially at night.	Switch PoE budget vs total draw (with IR/heaters).	PoE budget	Recalculate budget; offload to another switch/injector.
Offline on a regular interval.	DHCP lease time; reservations; duplicate IPs.	DHCP / addressing	Reserve IPs, lengthen lease, fix conflicts.
One camera reboots repeatedly.	Cable run length/condition; delivered PoE at distance.	Cabling / voltage drop	Re-terminate/replace/shorten; verify delivered watts.
Reachable by ping, 'offline' in NVR.	Inter-VLAN firewall rules NVR→camera.	Firewall / VLAN	Allow the NVR→camera ports across the VLAN.

Reference

Commands and settings paths

Ping the camera continuously

ping -t <camera-ip> (Windows) / ping <camera-ip> (Linux/mac)

Where: From the NVR and from the camera's VLAN.

Expected: Replies are steady; drops correlate with the failure timing.

Failure means: Periodic loss suggests DHCP/IP; total loss suggests power/cabling/firewall.

Safe next step: Match the pattern to the layer (PoE, DHCP, cable, firewall).

Check the switch PoE status

Switch admin > PoE per-port + total budget usage

Where: In the PoE switch's admin UI.

Expected: Total PoE usage is comfortably under the switch budget with headroom.

Failure means: Near-budget usage (worse at night) explains cameras dropping under load.

Safe next step: Offload cameras or use a higher-budget switch; size with the PoE calculator.

Verify the DHCP lease/reservation

Router/DHCP server: lease list + reservations for each camera

Where: In the DHCP server (router or NVR).

Expected: Each camera has a reservation and a sane lease time; no duplicate IPs.

Failure means: A short lease or a conflict shows as periodic drops.

Safe next step: Add reservations, lengthen the lease, and resolve conflicts.

Hardware boundary

Hardware and platform boundary

Change only when

Move to a switch with adequate PoE budget and reserved addressing before adding more cameras — power and IPs are the usual ceiling.

Evidence that matters

Switch total PoE budget (the binding limit), PoE class per camera (incl. IR/heater draw), solid Cat5e+ runs, and DHCP reservations.

Evidence that does not matter

Camera megapixels — an offline 4K camera records nothing; reliability beats resolution.

Avoid

Loading the PoE switch past 80%, leaving cameras on DHCP without reservations, or resetting cameras for firewall issues.

Related tool/calculator

Use the linked calculator or tool to turn this runbook into numbers for your exact setup.

PoE budget calculator

Last reviewed

2026-06-02 · Reviewed by HomeTechOps. Built from June-2026 research verified against PoE standards (FS.com), DHCP-lease behavior, and installer troubleshooting; leads with the one-vs-many + timing split, the hourly-drop = DHCP-lease signature, and the PoE-budget cause, cross-linking the PoE budget calculator and the camera-VLAN isolation guide.

Sources/assumptions

Assumes a PoE IP camera on a managed or unmanaged PoE switch with DHCP from the router/NVR.
Per-camera PoE draw varies with IR/heater state — use the camera datasheet, not a guess.
On an isolated camera VLAN, 'offline' to the NVR can be a reachability/firewall issue, not the camera.

Source-backed checks

HomeTechOps turns official docs and conservative safety rules into a shorter runbook. These links are the source trail for the page direction.

Frigate docs: Recommended hardwareUsed for detector inference times, the cameras ≈ (1000 ÷ inference_ms) ÷ detect_fps capacity model, and the current 'Coral no longer recommended for new installs' guidance.Frigate docs: Camera setup (detect vs record streams)Used for the detect-on-substream / record-on-main pattern that drives bandwidth and detector load.FS.com: Understanding PoE standards and wattageUsed for the 802.3af/at/bt source-vs-delivered power figures and the switch total-PoE-budget constraint.FS.com: Running 10GBASE-T over Cat6 vs Cat6a vs Cat7Used for the 10GBASE-T distance facts (Cat6a 100m, Cat6 ~55m) and the 2.5/5GBASE-T (802.3bz) on-Cat5e-to-100m point behind 'why does my 2.5GbE only link at 1GbE'.Frigate documentationUsed as the first-party reference for Frigate camera setup, detectors, recording, and configuration.FCC: Home network tipsUsed for router placement, congestion, and baseline home-network troubleshooting guidance.

Diagnostic rule

1. Check the simplest signal first.
2. Change one thing at a time.
3. Prove the stream/reachability before deep config.
4. Stop when the evidence says the risk moved.

FAQ

My cameras drop offline at night — what causes that?

Almost always PoE budget. IR illuminators and heaters raise a camera's draw after dark, and if the switch's total PoE budget is near its limit it sheds cameras under that load. Size the real draw with the PoE budget calculator and keep total load under ~80% of the switch budget; offload some cameras to another switch or injectors.

A camera goes offline every hour — why?

A regular, clock-like drop is the signature of a short DHCP lease renewing (or an IP conflict). Give each camera a DHCP reservation or static IP, lengthen the lease time, and make sure no two devices share an address. That usually ends the periodic drops.

The camera pings fine but the NVR says it's offline — what now?

That's a reachability/firewall problem, not a dead camera. If your cameras are on an isolated VLAN, a tightened inter-VLAN rule can block the NVR from reaching the camera's RTSP/ONVIF ports. Allow the NVR→camera path — see isolate cameras on a VLAN for the camera-specific rule order and local NTP. Don't factory-reset the camera for a firewall issue.