The fastest repair is usually the one that proves which layer failed before changing anything. This field workflow moves from power and link, through addressing and streams, to recording and remote access while preserving the evidence that explains intermittent faults.
Define the failure before changing it
Start by writing the exact symptom, affected cameras and last known good time. ‘Camera down’ can mean no power, no Ethernet link, an unreachable IP address, a stream the recorder cannot decode, or a recorder that shows live video but is not writing files. Check whether one camera, one switch, one recorder or the whole remote site is affected; that scope often points directly to the shared component. Photograph status LEDs and record switch port, camera address, recorder channel and current time before rebooting. Reboots erase useful clues and can make a weak cable or exhausted PoE budget look temporarily healthy. If the failure is intermittent, compare its time with infrared switching, heaters, rain, scheduled reboots, network backups and UPS events. The aim of the first five minutes is not to fix the system—it is to reduce the fault to one layer and create a repeatable test.
Prove power, PoE and the cable
For a completely dead camera, prove power before touching software. Check the camera or switch-port LEDs, confirm that PoE is enabled, and compare the camera’s maximum power class with both the port limit and the switch’s total PoE budget. Night failures commonly appear when infrared LEDs or heaters raise consumption. Move the camera to a known-good short patch lead and a known-good port; then put a known-good PoE device on the suspect cable. That A/B test distinguishes camera, port and permanent link far better than replacing several items at once. Inspect outdoor joints for water, corrosion, crushed cable and copper-clad aluminium. A link light proves negotiation, not cable quality under load. If the switch exposes PoE telemetry, record voltage, power draw, denied-power events and link flaps before disconnecting anything.
Test addressing, VLAN and reachability
When power and link are present, test local network reachability. Confirm the camera address, subnet mask, gateway and VLAN, then look for duplicate IP addresses or a DHCP lease that changed. Ping is useful but not decisive because a device or firewall may block it; the camera web interface, ARP table, switch MAC table and recorder discovery page provide additional evidence. Test from a device on the same VLAN first. If local access works but the recorder cannot connect, verify the recorder’s route, firewall policy, credentials and time. If discovery works but manual connection does not, check whether the product is actually registered as conformant for the ONVIF profile you need—not merely advertised as ‘ONVIF compatible.’ Preserve a known-good static address plan or DHCP reservations so a power cycle cannot silently move cameras.
Separate stream faults from camera faults
If the camera opens in a browser but video is black, frozen or repeatedly reconnecting, compare the main and substream. A working low-resolution stream points toward codec, resolution, profile level, decoder capacity or bandwidth rather than a dead sensor. Reduce one variable at a time: choose a supported codec, conservative frame rate and known-good resolution; then restore quality stepwise. Check how many simultaneous clients the camera allows and whether another VMS, phone or browser is consuming sessions. On a congested network, review packet loss, port errors and throughput across every hop instead of relying on an internet speed test. A live image with frequent macroblocking or multi-second stalls usually demands a network or decode investigation before camera replacement.
Prove the recording chain
When live view works but footage is missing, test the recording chain separately. Confirm the channel is enabled, the schedule covers the current day, the correct stream is selected, the disk is healthy and the retention database is not rebuilding. Trigger a controlled event while watching the recorder’s recording icon, wait two minutes, then search and export that exact period. For motion recording, verify camera time, recorder time, event subscription, detection zone and pre-record buffer. A green hard-drive status alone does not prove every channel is writing usable video. Review system logs for disk errors, authentication failures, time jumps and stream interruptions. Never initialize or format a drive during diagnosis until required footage is protected and the consequences are understood.
Diagnose night-only failures
Night-only faults require a moving-subject test. If the view turns white, look for infrared reflecting from a wall, soffit, dirty dome, rain, insects or spider webs close to the lens. If the scene is bright but faces smear, the exposure is probably using a shutter too slow for movement; add or reposition light and set a defensible minimum shutter rather than chasing gain. If the camera reboots as darkness falls, return to the PoE test because infrared and heaters increase load. Save a daytime reference and a night reference with a person walking through the evidence zone. A static garden can look excellent while every moving face is unusable.
Restore remote access safely
Treat remote viewing as a separate service after local live view and recording are proven. Check whether the recorder has correct DNS, gateway and time, whether the cloud or VPN session is healthy, and whether the user account still has permission. Test on mobile data as well as local Wi‑Fi so cached local access is not mistaken for true remote access. Avoid ‘fixing’ the problem by forwarding recorder ports directly to the internet. Capture logs and configuration before firmware changes; then update only from the manufacturer’s authenticated support channel, verify the release notes and retest live view, recording, export and alerts. Close the job with the root cause, the measurement that proved it and the final verification—not just ‘rebooted, now OK.’
Leave a repeatable fault record
Build a fault record that another technician can repeat. Include the symptom in the user’s words, affected asset IDs, topology, firmware, timestamps, tests performed, readings, configuration changes and links to exported logs. Separate observation from conclusion: ‘port 7 logged 43 link transitions between 01:12 and 01:19’ is useful; ‘bad network’ is not. If replacing hardware appears to solve the issue, run the original component in a controlled test or preserve it for analysis rather than declaring it failed without proof. Schedule a follow-up during the condition that triggered the fault—after infrared activates, during peak traffic or after rainfall. That last verification distinguishes a repair from a temporary recovery and gives the owner a defensible maintenance history.
Change one variable at a time. If you swap the port, cable, power source and stream settings together, a temporary recovery tells you nothing about the root cause—and the fault is likely to return.
Before you sign off
- Record scope and last-known-good time before rebooting
- A/B test camera, PoE port and cable with known-good parts
- Verify address, VLAN, route, credentials and clock
- Compare main stream with a conservative substream
- Trigger, search and export a controlled recording
- Repeat the test after dark with a moving subject
- Document the root cause and final proof
Can another person prove the system still works?
Record the final view, night image, bitrate, alerts, firmware and access method. A system is not finished until the owner can verify recording and export without the installer standing beside it.
Every site is different. Confirm manufacturer instructions, electrical requirements, privacy obligations and local regulations before installation.
Sources used for this guide
Primary standards and manufacturer documentation are linked so you can verify thresholds, features and current product behaviour.
Frequently asked questions
Why is my security camera offline?
Start with scope, power and Ethernet link, then verify its IP address, VLAN, route and credentials. A known-good port and short cable can quickly separate a camera fault from the permanent link.
Why does a PoE camera work during the day but fail at night?
Infrared LEDs and heaters can raise power demand after dark. Check the camera’s maximum draw, switch PoE budget, cable voltage drop and denied-power or link-flap logs.
Why can I see live CCTV but no recordings?
The live stream and recording chain are separate. Check the schedule, selected stream, disk state, event subscription and time, then trigger and export a controlled test clip.
Should I factory-reset an offline security camera?
Not first. A reset can erase addresses, logs and configuration without fixing cable, PoE or network faults. Capture evidence and isolate the failed layer before resetting.