Editorial note: This worksheet helps a household organize records after a security event. It is not legal advice and does not replace instructions from police, fire services, an insurer, a monitoring provider, or a qualified investigator. Preserve original files, do not edit source media, and do not enter an unsafe property to collect evidence.
A door sensor may report 02:14, a camera may show 02:13, a monitoring call may arrive at 02:16, and a neighbor may remember “about 2:20.” Those records can describe the same event while using different clocks, time zones, delays, or human estimates. A home-security incident timeline turns scattered records into a traceable sequence without pretending that every timestamp is exact.
The working rule is simple: keep the original value, record where it came from, add a normalized time only when the conversion is documented, and label uncertainty. The finished worksheet should let another person trace every row back to a source.
Start with safety and authority
Call emergency services when a person may be in danger, a fire or gas risk exists, an intruder may still be present, or local guidance says to report immediately. Do not delay a call while downloading video. If a scene may be unsafe, stay out and follow instructions from responders.
Name one timeline owner and one backup. The owner gathers copies, records source details, and protects the untouched originals. The backup checks conversions and confirms that no file was silently changed. Limit access to people who have a real need. Camera clips, access logs, addresses, phone numbers, and witness names can expose residents and routines.
Use one row per observable event
| Field | What to record | What not to do |
|---|---|---|
| Row ID | A stable reference such as T-001 | Do not renumber rows after sharing the worksheet |
| Original timestamp | The exact date, time, zone, and display format shown by the source | Do not overwrite it with a converted value |
| Normalized timestamp | A documented conversion to the chosen reference zone | Do not add one when the source zone is unknown |
| Uncertainty | Exact, device-reported, delayed, rounded, estimated, or bounded by two known events | Do not turn “around 2:20” into 02:20:00 |
| Source | Device, app, monitoring record, call log, message, witness, receipt, or authority reference | Do not write “camera” when several cameras exist |
| Event | One factual observation in plain language | Do not mix observation and theory |
| Original file or record | Filename, export ID, case number, message ID, or screenshot reference | Do not point only to a renamed working copy |
| Collector | Who obtained the record and when | Do not leave custody unclear |
| Notes | Clock offset, delivery delay, missing interval, or follow-up needed | Do not place passwords, door codes, or recovery secrets here |
Keep facts and interpretations in separate columns. “Back-door contact changed from closed to open” is an observation. “The intruder entered through the back door” is an interpretation that may require video, damage, witness, and access evidence.
Choose a reference clock
Pick one reference zone for the normalized column, usually the incident location’s local time with the UTC offset written out, for example 2026-08-15 02:14:18 AEST (UTC+10). For a cross-border case or a long investigation, UTC can be easier. The important point is consistency.
Record the location’s daylight-saving status on the incident date. Do not rely on the computer’s current setting when the event happened in another season. If a device shows only “2:14 AM,” preserve that value and mark the zone unknown until the device, account, or export explains it.
Use the security-camera timestamp and clock-drift audit to test device time before an incident. This worksheet has a different job: it reconciles records after an event while retaining their original values.
Inventory every source before building the sequence
- alarm-panel and sensor event history;
- monitoring signals, calls, texts, app events, and case references;
- camera cloud clips, local recordings, thumbnails, stills, and export receipts;
- smart-lock activity, named user codes, manual-key events where available, and door-position sensors;
- doorbell presses, motion events, package events, and two-way-audio sessions;
- router, access-point, UPS, power, and internet-outage records;
- phone call history, voicemail, messages, and emergency alerts;
- vehicle, garage, gate, intercom, lighting, and automation history;
- neighbor or building-system records obtained with permission;
- photos of damage, receipts, repair records, and authority case numbers; and
- witness observations recorded in the witness’s own words.
Make a source register before copying individual events. For each source, record the owner, product or service, device name, serial or account reference where safe, physical location, app or export route, stated time zone, retention limit, export date, collector, and storage location. This catches fast-expiring clips before the household spends time formatting the timeline.
Preserve originals before reviewing them
Export the highest-quality original available through the product’s supported route. Save the untouched file first. Create a working copy for viewing, redaction, transcoding, or annotation. Record the original filename, size, creation and export dates, source URL or app path, and a checksum when the workflow supports one.
Do not trim the only copy, replace audio, change frame rate, add captions, or repeatedly send a clip through messaging apps. Those actions can remove metadata or change compression. Follow the home-security evidence preservation guide for original files, checksums, custody, storage, and controlled sharing. Apple Home users can also use the HomeKit camera evidence export checklist.
Measure clock offsets without rewriting history
A device clock can be early or late. An app may display local time while an export stores UTC. A server may timestamp receipt rather than capture. A notification may arrive seconds or minutes after the underlying event. Record each of those as a separate clock or delay.
- Find a shared event visible in two records, such as a door opening that appears in both a sensor history and a camera.
- Write both original timestamps exactly as displayed.
- Confirm each source’s time zone and whether the time marks capture, upload, processing, delivery, or display.
- Calculate the observed offset and state the formula.
- Repeat with another shared event later in the period to check for clock drift.
- Apply a correction only to the normalized column and keep the original value untouched.
Example: Camera A shows a door opening at 02:13:42. The alarm event log shows the same physical opening at 02:14:07. If both zones are confirmed and the events match, the observed difference is 25 seconds. Write “Camera A was 25 seconds earlier than the alarm log at this checkpoint.” Do not claim the alarm log is the true clock unless an independent reference supports that conclusion.
Separate event time from delivery time
One occurrence can create several legitimate rows:
- sensor changes state;
- hub receives the signal;
- cloud service records the event;
- camera starts or saves a clip;
- push notification reaches a phone;
- monitoring center receives an alarm;
- monitoring agent starts a call;
- contact answers or misses the call; and
- authority or household response begins.
Do not collapse these into one timestamp. Delivery delay can explain why a phone alert follows a camera frame without proving that the underlying event happened later. The monitoring call-delivery test helps measure phone and carrier behavior before a real alarm.
Build the first pass without a theory
Sort rows by normalized time when available, then by original time and source. Add facts before conclusions. A useful first pass might read:
- T-001 — driveway camera motion event begins;
- T-002 — porch light automation runs;
- T-003 — back-door contact reports open;
- T-004 — indoor camera records motion;
- T-005 — alarm hub enters alarm state;
- T-006 — monitoring service logs signal receipt;
- T-007 — primary contact receives a call; and
- T-008 — household calls the listed emergency number.
After that sequence is stable, add a separate analysis section for likely relationships, open questions, and conflicts. This reduces confirmation bias and makes later corrections easier.
Mark confidence and uncertainty
| Label | Meaning | Example |
|---|---|---|
| Exact record | A source provides date, time, zone, and event ID | Monitoring signal receipt at 02:14:11 UTC+10 |
| Device-reported | The device provides a time but clock accuracy is not independently known | Camera clip starts at displayed 02:13:42 |
| Delayed delivery | The record marks receipt or notification rather than the underlying event | Push alert received at 02:14:35 |
| Bounded | The event occurred between two known records | Power failed after the last frame at 02:18 and before router offline at 02:19 |
| Estimated | A witness or record gives an approximate time | Neighbor heard glass around 02:20 |
| Unknown | The source does not support a safe time claim | Undated screenshot from an unknown phone |
Use ranges instead of false precision. A witness who says “between 2:15 and 2:25” supplied a ten-minute interval, not a point at 2:20. A clip with a missing first frame may show that an event had already started, not when it began.
Handle gaps and conflicts openly
Create a gap register. Each gap should name the missing period, affected source, likely reason, retention deadline, recovery attempt, owner, and status. Common causes include a disabled recording mode, expired cloud retention, full microSD card, offline camera, power failure, weak Wi-Fi, privacy mode, a deleted user, a changed subscription, or an export that omitted event metadata.
When two records conflict, keep both. Add a conflict note stating the original values, confirmed zones, known clock offsets, possible delay, and next check. Do not delete the inconvenient row. The conflict itself can reveal a clock problem, an upload delay, or a device outage.
For local storage, use the microSD card health audit. For outage records, use the UPS backup-power runtime test and the system’s own recovery instructions.
Protect identities, codes, and private spaces
The timeline should identify named users only when needed. Replace guest codes, alarm PINs, app passwords, verbal passcodes, Wi-Fi credentials, and recovery keys with controlled references. Do not paste a secret into an event description.
Keep an unredacted master only where required and authorized. Make a separate sharing copy that masks unrelated faces, neighboring homes, license plates, children, medical details, and private interior spaces as appropriate. Record who made each redaction and keep the original untouched.
If a shared user, former resident, or installer may still have access, run the security-camera shared-user access audit and the home-security app permission audit. Do not remove a user before preserving relevant logs when authorities or counsel have told you to retain them.
Create a controlled incident package
A clean package has a cover sheet, source register, timeline, gap register, conflict register, original-file index, working-copy index, checksum list where used, custody record, export receipts, and a change log. Put authority or insurer case numbers on the cover sheet, not inside every filename.
Use filenames that sort and remain understandable, such as T-003_back-door-contact_original-export.json and T-004_indoor-camera_working-copy.mp4. Never rename the only original without recording its prior name.
Record every package version. If a new clip arrives, issue a new version and add rows; do not silently replace the previous package. A short change log can state “v1.1 added Camera B export and corrected its documented UTC offset; original timestamps unchanged.”
45-minute incident timeline drill
- Minutes 0-5: choose a harmless test event, confirm no emergency response will be triggered, name the timeline owner, and choose the reference time zone.
- Minutes 5-10: open and close one test door, walk through one camera zone, and create one approved alarm or app event in test mode.
- Minutes 10-16: collect the sensor event, camera clip, app alert, phone receipt time, and any monitoring test record. Preserve originals first.
- Minutes 16-22: create the source register with device names, zones, time display, export route, collector, and retention limits.
- Minutes 22-28: enter one observable event per row, keeping original and normalized timestamps separate.
- Minutes 28-33: compare the shared door event across the sensor, camera, and phone. Record clock offsets and notification delay without declaring an unsupported true clock.
- Minutes 33-37: add uncertainty labels, one gap check, and one conflict check. Confirm that no secret or unrelated private detail entered the worksheet.
- Minutes 37-41: have the backup trace three rows to their original files and verify the copies were not substituted.
- Minutes 41-45: exit test mode, confirm normal operation, record corrections and owners, and set the next drill date.
A passing drill proves that another authorized person can find the source behind every row, explain each time conversion, distinguish event time from delivery time, and identify gaps without editing the originals.
FAQ
Which time zone should a home-security incident timeline use?
Choose one reference zone and write its UTC offset. Keep every source’s original timestamp and zone in separate fields. Do not convert a source whose zone is unknown.
Can I correct a camera timestamp that is wrong?
Add a documented normalized time and clock-offset note, but do not replace the original timestamp. Preserve the source value so another person can review the calculation.
Should a push notification and sensor event share one row?
No. The sensor event and notification delivery are different observations. Separate rows show the delivery delay and prevent the phone receipt time from being mistaken for the event time.
What if two devices disagree about the time?
Keep both original values, test their time zones and offsets, and record a conflict. Use a normalized value only when the conversion can be explained.
Can I trim a video before sending it?
Preserve the original export first. Make a labeled working copy for trimming or redaction, record the change, and follow instructions from the receiving authority or insurer.
