An internet outage is not one event for a home-security system. The router can lose its WAN connection while local Wi-Fi stays online. The access point can fail while the modem still works. A hub can keep sensors and a siren active but lose app alerts. Cameras can continue to record locally, stop recording, or recover with a gap that is easy to miss.
A written test log turns those separate outcomes into evidence. It records what failed, what kept working, how long each change took, and whether the system recovered without manual repair. This guide provides a repeatable log for planned tests and real outages. It does not promise that any product will work offline; the point is to verify the exact equipment, plan, network, and settings installed in your home.
What this outage log adds
A general home-security-without-internet guide explains the functions that may remain available. This log is the operating record. It gives each failure state a start time, expected result, observed result, evidence, recovery time, owner, and retest date.
Use it for three kinds of records:
- Planned exercise: a controlled router, modem, or WAN test performed with everyone informed.
- Real incident: an unplanned outage caused by the provider, equipment, power, configuration, or an unknown fault.
- Corrective retest: a repeat of the failed step after a setting, battery, network device, plan, or procedure is changed.
Do not combine several outages in one row. Use one row per failure event so duration, evidence, and corrective work stay attributable.
Home security internet outage test log: required fields
A useful record is specific enough that another household member can repeat the test. Capture these fields before changing the network:
| Field | What to record | Why it matters |
|---|---|---|
| Event ID | A short unique ID such as OUT-2026-08-14-01 | Links screenshots, tickets, and retests to one event. |
| Event type | Planned exercise, real incident, or corrective retest | Separates controlled results from an uncontrolled outage. |
| Start trigger | WAN cable removed, modem powered off, access point powered off, provider loss, or power failure | Shows which layer actually failed. |
| Start and end time | Local time with time zone, plus total duration | Supports alert-delay and recovery calculations. |
| System state before test | Armed mode, sensor status, camera state, battery level, plan, app version, and firmware | Prevents a pre-existing fault from being blamed on the outage. |
| Expected behavior | The documented outcome for siren, sensors, app, monitoring, cameras, locks, and automations | Makes pass or fail objective. |
| Observed behavior | What happened, including exact delays and missing functions | Records the result without relying on memory. |
| Evidence | Photo, screen recording, event export, camera clip, monitoring call time, or router log | Allows later review and vendor support. |
| Recovery result | Automatic, manual restart, re-pair, re-login, or unresolved | Exposes systems that appear normal but need repair. |
| Owner and due date | Person responsible for the fix and the next test date | Turns a failed test into a closed action. |
Copyable outage event template
Copy this block into a note, spreadsheet, or maintenance record. Keep timestamps in one time zone.
Event ID: Event type: Planned / Real / Corrective retest Date and time zone: Start time: End time: Failure introduced or observed: Internet provider and modem/router model: Security hub and firmware: Monitoring plan: Armed mode before event: Expected local alarm result: Observed local alarm result: Expected remote alert result: Observed remote alert result and delay: Expected monitoring result: Observed monitoring result and delay: Camera live-view result: Camera recording result: Smart-lock local result: Automation result: Power and battery result: Evidence file names or links: Recovery start time: Full recovery time: Automatic or manual recovery: Missing events or clips after recovery: Pass / Conditional pass / Fail: Corrective action owner: Corrective action due date: Retest date and linked event ID: Notes:
Define the failure before the test
“Internet down” is too broad for diagnosis. Pick one failure state and record it in the log.
| Failure state | How to introduce it safely | What it isolates |
|---|---|---|
| WAN loss only | Disconnect the modem-to-router WAN link while leaving the router and Wi-Fi powered | Internet dependency while the local network remains available. |
| Modem or gateway loss | Power off the modem or provider gateway | Provider-edge failure and any automatic cellular path. |
| Wi-Fi access-point loss | Power off the access point, leaving the hub and modem state documented | Camera, lock, and device dependence on local Wi-Fi. |
| Router loss | Power off the router after confirming the test will not disrupt medical or safety devices | Local DHCP, Wi-Fi, DNS, and routing dependence. |
| Whole-home power loss | Use a safe circuit or device-level simulation; do not improvise electrical work | Battery and UPS behavior in addition to network failure. |
| Cellular unavailable | Do not block a live emergency signal. Use documented diagnostic status or provider-supported testing | Whether the claimed backup path is actually registered and available. |
If you need to evaluate the backup network itself, use a separate backup internet plan. Do not silently replace the failed WAN with a phone hotspot during the baseline test; that changes the failure state.
Pre-test control record
Run a control before disconnecting anything. Arm the system in the mode used for the exercise. Confirm every tested sensor shows ready, the siren is available, cameras have current timestamps, the app can receive a normal test event, and monitoring status is current. Capture a screenshot of the device list and time.
Also record:
- hub, keypad, modem, router, access point, camera, and smart-lock model numbers;
- hub, camera, router, and app software versions;
- battery percentage or measured voltage where available;
- whether each camera uses cloud storage, a memory card, a base station, a recorder, or more than one path;
- whether the security plan includes cellular backup and professional monitoring;
- the phone network and whether the test phone is on home Wi-Fi or mobile data;
- the exact local time and the clock source used for all observations.
A current home-security equipment inventory makes this step faster. If a control check fails, stop. Record a separate maintenance issue instead of producing an invalid outage result.
Set pass criteria before disconnecting the network
Pass criteria must reflect product documentation and your own risk plan. A possible test matrix is below; replace every target with the outcome your equipment is meant to deliver.
| Function | Example pass criterion | Evidence |
|---|---|---|
| Door or window sensor | Hub receives the event and local siren follows the armed rule | Video with the sensor, keypad, hub, and clock in view. |
| Local siren | Siren activates at the expected volume and duration without internet | Timestamped video; avoid unsafe sound exposure. |
| App status | App shows loss of connectivity within the documented time | Screen recording on mobile data. |
| Cellular backup | Hub reports backup registration and sends the permitted test event | Hub diagnostic, app history, or provider confirmation. |
| Professional monitoring | Monitoring receives an approved test signal within the agreed window | Call, text, or portal timestamp and test reference. |
| Camera recording | Selected cameras record to the expected local destination for the full outage | Clips with continuous timestamps before, during, and after the event. |
| Smart lock | Key, keypad, or local credential works as planned; remote control is correctly unavailable or retained | Video and lock event history. |
| Recovery | Devices reconnect automatically, event history reconciles, and no device remains stale | Post-recovery device list and clip timeline. |
Use Pass only when every required function meets its criterion. Use Conditional pass when safety functions work but a non-safety function misses its target and has an accepted workaround. Use Fail when a required alarm, notification, monitoring, recording, access, power, or recovery function does not meet the target.
Run a 60-minute internet-outage log drill
This sequence creates comparable records without rushing recovery checks. Adjust it only when the manufacturer or monitoring provider gives a different test method.
- Minute 0: start the log. Record the trigger and exact time. Photograph the disconnected cable or powered-off device so the failure state is clear.
- Minutes 1–5: observe transition. Record when the hub, app, cameras, and monitoring portal first report offline or backup status. Do not count a banner without a timestamp.
- Minutes 6–15: test local alarm behavior. Use an approved test sensor or system test mode. Confirm the sensor event, keypad state, and local siren. Never trigger emergency dispatch without following the provider’s test procedure.
- Minutes 16–25: test remote paths. Put the observer phone on mobile data. Record app status, push notification, SMS, call, and monitoring outcomes separately.
- Minutes 26–35: test cameras. Check live view, motion detection, local recording, cloud recording, and recorder access as separate functions. Do not assume a visible camera LED proves a clip exists.
- Minutes 36–45: test access and automations. Use a safe smart-lock credential and one non-critical automation. Record local and remote control separately.
- Minutes 46–55: hold the state. Look for battery drain, repeated reconnect attempts, overheating, stale device states, or recording gaps that a short test would miss.
- Minute 56: restore the network. Reconnect the exact component removed at minute 0. Record each recovery milestone rather than one final time.
- After minute 60: reconcile. Export event history, review every camera timeline, confirm devices are current, and link any failure to a correction ticket.
For power-related testing, pair this record with a home-security UPS runtime test. Internet recovery and battery runtime are different measures and should not share one pass result.
Log local alarm behavior separately
The local sensor-to-hub-to-siren path is the first safety check. Record the sensor name and zone, armed mode, entry delay, event time, siren start time, and whether the keypad showed the correct zone. If the siren fails, do not continue as though the system passed because a phone notification arrived.
When several sensors use different radios or bridges, test one representative device from each path. A directly paired contact sensor, a Wi-Fi camera, and a bridged smart lock do not prove one another’s offline behavior.
Prove cellular backup instead of inferring it
A cellular icon can mean registered, connecting, standby, or unavailable depending on the product. Record the exact label and time. Use the manufacturer’s or monitoring provider’s approved test process to confirm whether a signal reached the service. Note the event type because some plans or systems send alarm events over cellular but not camera video, live view, automation traffic, or every app notification.
Record these results separately:
- time from WAN loss to cellular-ready state;
- time from test event to app, SMS, call, or monitoring receipt;
- which event types crossed the backup path;
- whether a subscription or active monitoring plan was required;
- whether the hub returned to broadband automatically after restoration;
- whether any events were duplicated or arrived out of order.
If plan status affects the result, record the plan name and test date. For Abode, verify current options on the official plans page; do not copy an old plan assumption into a new test.
Audit camera evidence, not just live view
Camera systems can pass live view and fail recording, or record locally while remote live view is unavailable. For each tested camera, record the storage destination, power source, detection method, event timestamp, clip start delay, clip length, and whether audio was present. Review the stored clip after the network returns.
A camera row should answer five questions:
- Did the camera stay powered?
- Did it detect the test motion?
- Did it create a clip or continuous-recording segment?
- Where was the file stored during the outage?
- Did the file appear in the expected app, recorder, or archive after recovery?
Check removable storage before relying on it. A separate camera microSD health audit can expose a full, read-only, counterfeit, or worn card that an outage test alone cannot diagnose.
Record smart-lock and access behavior without creating a lockout
Keep a physical key or another verified entry method available. Test local keypad codes, phone credentials, auto-lock, door position, remote commands, and guest access as separate functions. Write “not expected offline” when a cloud command is intentionally unavailable; do not score an undocumented function as a failure.
Record whether the lock’s event history appears immediately after recovery or arrives later. If the security system depends on the lock for arming, disarming, or occupancy rules, test that rule once with the door open and once closed only when it is safe.
Recovery is a test phase, not the end
Many hidden failures happen after the connection returns. A camera can remain offline, a hub can stay on cellular, or event history can omit the outage window. Log each recovery milestone:
- WAN link restored;
- router reports internet access;
- hub reports broadband;
- app shows the hub online;
- each camera appears current;
- live view works;
- local and cloud clips are visible;
- smart locks and bridges are current;
- monitoring portal shows normal status;
- all events are present and in time order.
Calculate recovery time from network restoration to the last required function returning, not to the first green status icon. A system with a 90-second hub recovery and a 22-minute camera recovery has a 22-minute full recovery for that test scope.
Turn every failure into a correction ticket
A failed row needs a cause hypothesis, owner, due date, change, and retest. Useful cause classes include internet provider, modem, router, Wi-Fi coverage, DNS, hub, device firmware, battery, power supply, storage, subscription, monitoring account, notification settings, phone permissions, and user procedure.
Do not close a ticket because a restart fixed the symptom once. Record the restart as the change, repeat the same failure state, and link the new event ID. If the failure repeats, escalate with timestamps, firmware versions, network topology, screenshots, and exported logs.
If an outage caused a false alarm or dispatch issue, link the event to a false-alarm log. One record documents network failure; the other documents the alarm event, cause, correction, and retest.
Compare planned tests with real incidents
Real incidents often expose conditions a planned test misses: an outage may occur overnight, batteries may already be low, the home may be unoccupied, or the provider may restore service in stages. Keep the same fields for both record types so you can compare them.
Review the log quarterly for:
- repeat failures by device, zone, provider, or failure state;
- longer transition or recovery times;
- battery runtime decline;
- camera gaps tied to storage or Wi-Fi;
- cellular registration failures;
- notifications blocked by phone settings;
- manual recovery steps that only one person knows.
Trend the measure that affects the household decision. For example, alert delay can be tracked with a dedicated home-security alert-delay test, while this log keeps the entire outage sequence together.
Privacy and retention rules
An outage log can contain alarm times, device names, floor-plan clues, phone numbers, monitoring account details, camera images, and entry history. Store only what is needed for maintenance. Avoid placing access codes, passwords, recovery keys, full account numbers, or precise camera views in a shared sheet.
Use neutral device labels when the file may be sent to a vendor. Keep sensitive evidence in a protected folder, give the log a retention date, and delete duplicate exports after a case closes. Redact household names and access details before sharing screenshots.
When to stop the test
Restore normal service immediately if the exercise interferes with a medical device, fire or life-safety service, active emergency, household member’s safe entry, required monitoring, or another critical connection. Stop if equipment becomes hot, a battery swells, electrical damage is visible, or you cannot confirm that the monitoring account is in the correct test state.
A planned test should create evidence, not risk. If the system’s approved test method is unclear, ask the manufacturer or monitoring provider before disconnecting equipment.
Final review checklist
- The event has a unique ID, type, start trigger, start time, and end time.
- The control record proves the system worked before the failure.
- Local alarm, remote alerts, monitoring, cameras, locks, power, and recovery have separate results.
- Every pass or fail is tied to a stated criterion and evidence.
- Full recovery time uses the last required function, not the first online indicator.
- Every failed result has an owner, due date, and linked retest.
- Sensitive access and household data are excluded or protected.
- The next planned test date is on the maintenance calendar.
Frequently asked questions
How often should I run a home-security internet outage test?
Run one after installation, after a network, plan, hub, camera, or monitoring change, and on a schedule that matches the household’s risk. A quarterly test is a practical starting point for many homes, but product guidance and local needs should set the interval.
Does a working siren prove the system has cellular backup?
No. A local siren proves the local alarm path worked in that test. Cellular backup must be verified separately through approved diagnostics, a permitted test event, and monitoring or provider evidence.
Should I power off the router or disconnect only the internet?
Those are different tests. WAN loss keeps the local network available. Router loss removes Wi-Fi, routing, and other local services. Run them as separate event IDs so the results remain attributable.
Why do I need to inspect camera clips after recovery?
A camera can appear online and still have a missing, late, corrupt, or incomplete recording. Inspect the timeline and stored file across the outage window before marking recording as passed.
What is the right recovery time?
Measure from network restoration to the last required function returning. Record intermediate milestones too, such as hub online, app current, camera live view, recording available, and monitoring normal.
Can I test professional monitoring without causing dispatch?
Use only the monitoring provider’s approved test process. Confirm the account’s test state and the permitted event before triggering anything. Local rules and provider procedures differ.
