IP Camera Offline? A CCTV Troubleshooting Guide for NZ

If an IP camera is offline, first establish whether it has suitable power and a working network path. Then check addressing, authorised credentials and the recorder connection. If the camera is reachable but has no live picture, investigate the video service and stream settings. If live video works but footage is missing, investigate recording separately. Test one change at a time and finish by retrieving a new recording through the installed system.

Name the fault before changing equipment

Record the affected camera, last known working time, recorder message and whether other cameras are affected. Ask what changed: a password, firmware update, switch replacement, network policy or building work can narrow the investigation. Preserve relevant logs and configuration before restarting equipment.

Use these three starting points. Camera offline means the recorder cannot establish its required connection, but that message alone does not identify the failed layer. No live picture means a viewing path is failing even though the camera may still respond. Not recording means the expected footage is absent and needs storage, schedule and event checks.

Compare local and remote viewing. If local video and recording work but a phone connection fails, investigate the approved remote-access service and account permissions. Avoid treating an internet fault as proof that the camera or its local cable has failed. Agree any service interruption with the client and keep incident footage protected.

Check power and the PoE budget first

Identify how the camera is powered and compare its documented input requirement with the actual port or injector. Do not connect an unverified passive injector or assume every Ethernet socket supplies suitable power. Check the switch supply, port state, power allocation and any power-denied or overload messages.

An adequate switch total does not prove that one port supports the required power type. Conversely, a capable port does not create spare capacity in an exhausted shared budget. Review the complete connected load and the switch's allocation behaviour. The UniView NSW2020-6T-POE-IN switch is one catalogue example; use its exact specification rather than a general PoE label when selecting replacements.

Check conditions associated with the failure. A camera that restarts after dark may need investigation under illuminator, heater or motor load where fitted. That pattern is a clue, not proof of a power fault. A suitable endpoint test and switch logs are stronger evidence than an LED or a voltage reading beside the switch.

Isolate the cable and switch port methodically

Inspect accessible connectors, patch leads, weather protection and signs of water entry or strain. Substitute a known-good patch lead first where practical. If authorised, test the camera on a known-good compatible port and short lead, changing only one part of the path at a time. Keep labels and record the original connections.

A successful bench connection narrows the investigation towards the installed path or its configuration; it does not prove the cable alone is defective. Likewise, a failed test on a second port is inconclusive if that port has the same unsuitable power configuration. Record the conditions of each substitution.

Select a tester that answers the question being asked. Basic continuity does not certify a category-rated channel, prove throughput or establish adequate delivered PoE under load. Our cable, network and PoE tester guide explains the evidence each class of tool can provide. Follow the instrument's restrictions on live connections and use qualified personnel for mains-side work.

Confirm the intended IP network and recorder topology

Check the camera address, subnet mask and the route used by the recorder. Compare them with the approved network plan. A private camera network on an NVR's built-in PoE ports may be separate from the building LAN; a laptop connected elsewhere may therefore be unable to discover those cameras directly. Consult the recorder's documented topology before moving connections.

For DHCP installations, inspect authorised lease records and confirm the address associated with the device identity. For static addressing, investigate duplicates and configuration errors. A ping reply can come from another device using the same address, while a missing ping reply may reflect a policy that blocks it. Neither result alone proves the camera's health.

Ask the network administrator to check VLAN membership, routing and permitted services where relevant. Restore an approved path rather than disabling network security controls to make discovery work. Do not expose the camera to the public internet as a troubleshooting shortcut.

Check credentials and compatibility after connectivity

Use a named, authorised account to test the camera's supported management interface. Confirm that the recorder stores the current credentials and the required permissions. Avoid repeated guesses that can trigger lockout. A recent password change is a common configuration lead, but verify the actual authentication error before altering accounts.

Check the exact camera model, recorder model, firmware, driver and selected connection method. ONVIF compatibility is tied to documented profiles and registered product firmware, not simply a brand name. Use the ONVIF conformance guidance and the recorder manufacturer's supported-device information. A basic video connection does not establish support for every analytic event or audio feature.

If a firmware change is proposed, retain configuration backups, review compatibility and agree a maintenance window. Factory reset is a controlled recovery step after narrower checks, not the first response. It can remove addressing, accounts, image settings and recording relationships that still need to be reconstructed.

Reachable camera, but no live picture

Compare the camera's own supported view with the recorder and a second authorised client. Note whether the failure affects all streams or only one. Investigate codec, resolution, frame rate, bandwidth and client decoding limits using the exact device documentation. A working substream with a failing main stream provides a useful direction for testing without proving the final cause.

The Axis network troubleshooting guide identifies network capacity and device or client load as possible causes of streaming problems. Use that layered approach across brands while keeping settings and limits specific to the installed equipment. Do not apply a bitrate rule from a different camera as a universal threshold.

Make one temporary, documented change, reproduce the original viewing task and compare the result. If reducing stream demand helps, investigate the actual bottleneck before accepting a permanent reduction that could compromise the client's required image detail.

Live picture works, but recording is missing

Check that the correct camera is enabled for the required recording schedule, event and storage destination. Verify recorder time, camera time, time zone and daylight-saving configuration against the client's operating requirement. For New Zealand sites, a time mismatch can send an operator to the wrong part of the playback timeline.

Inspect disk or storage health, writable capacity, allocation, retention settings and recorder error logs. Do not initialise or format storage while investigating missing footage without explicit authorisation and the required preservation steps. A live image establishes neither stored footage nor a usable export.

Check the documentation for the actual NVR or VMS. The Axis Camera Station troubleshooting guide illustrates the distinction between connection and storage faults; its menu paths are not universal. If assessing a replacement, compare the recording requirements with the exact UniView recorder configuration or other specified platform, including the fitted storage.

Catch intermittent faults and prove the repair

Correlate failures with camera uptime, switch events, port errors, weather, night operation, DHCP changes and simultaneous failures elsewhere. Record timestamps in a consistent time zone. Several cameras failing together point towards a shared dependency worth checking, such as a switch, uplink or supply. They do not automatically establish that dependency as the cause.

After the repair, recreate the original condition for an agreed observation period. Confirm stable live viewing, generate a known event, find the new recording and export a sample. Include night-mode or other relevant load conditions when they were part of the complaint. Confirm that intended offline alerts and recovery behave correctly.

Close the job with the original symptom, evidence, change, successful repeat test and any outstanding monitoring. Our CCTV field tester guide supports local checks, while the installed recorder remains essential for proving the complete recording service.

Frequently asked questions

Why can I ping a camera that the NVR calls offline?

The address may be reachable while authentication, video services, protocol settings or compatibility fail. Confirm the device identity and test the recorder connection rather than relying on ping alone.

Does a PoE light prove the camera has enough power?

No. Check the required power type, port capability, shared budget and delivered power under representative load using appropriate equipment.

Should I factory-reset an offline camera first?

No. Preserve evidence and configuration, then check power, cabling, network and authentication. Use a reset only as an authorised recovery step with a documented reconfiguration plan.

How do I verify that the camera fault is fixed?

Repeat the original failing condition, confirm stable video, generate a new event, retrieve its recording and export a sample through the installed recorder.

Send your equipment schedule and project requirements to Essential Security Supplies for help with product selection, a trade quote and the documentation needed for your specification.