Clockwork: Why Accurate Time Keeps Buildings Recoverable

Why Time Becomes a Building Operations Problem

This episode starts with a familiar but costly scenario: a buildingwide access issue hits on a Friday afternoon, vendors arrive, and everyone has logs, footage, and alarms to review. The problem is that each system shows a different time. What should have been a short repair turns into a multi-day investigation, tenants stay disrupted, and teams lose time trying to prove what happened. The central point of the conversation is simple: timestamps feel boring until they undermine incident response, evidence, and recovery.

Rather than turning this into a technical deep dive on time protocols or device configuration, the episode stays focused on governance, evidence standards, and repeatable operational checks. The discussion is built for people who manage real buildings and real disruption: property managers, facilities leaders, IT stakeholders, and anyone responsible for coordinating vendors when systems fail.

Where Inconsistent Time Shows Up in Practice

Michael Harrington explains that inconsistent time becomes the loudest problem in the room when an incident happens. In day-to-day operations, it may go unnoticed. But during an outage or investigation, even a few minutes of drift between systems can make evidence hard to trust.

• Access logs and camera footage become difficult to correlate when doors, cameras, and alarms all show different times.
• Alarm investigations slow down because teams cannot sequence what triggered what.
• Tenant claims become harder to validate when the evidence does not align.
• HVAC schedules can run at the wrong times if clocks drift, creating comfort complaints that look like performance issues.
• Forensic reviews become less reliable when teams cannot prove whether a sensor failure happened before or after an alarm.

The conversation makes a strong operational case: time alignment is not just an IT hygiene issue. It directly affects tenant experience, vendor response, remediation speed, and confidence in the record of events.

Governance Matters More Than Protocol Details

One of the clearest takeaways in the episode is that consistent time needs ownership. In mixed vendor environments, no one should assume someone else is handling it. Michael says a clear owner should be named in O&M and handover documentation so the process survives staff turnover and vendor changes.

From his perspective, IT is often the best owner of authoritative time sources because IT usually manages the underlying network infrastructure. At the same time, facilities or property operations should own the policy itself: which systems must follow that time, how often alignment is checked, and what happens when drift appears.

The practical governance model discussed in the episode includes:

• Listing which systems must stay aligned.
• Naming who enforces the policy.
• Documenting how drift is identified and escalated.
• Including time requirements inside vendor scopes.
• Capturing the policy in O&M so it remains part of the building record.

The theme is straightforward: if time matters to tenant operations or evidence, it cannot live as an undocumented assumption.

What to Include in a Time Inventory

Teams do not need a massive audit to get started. The episode recommends building a short, prioritized inventory of the systems that produce timestamps and matter most during incidents.

• Access control systems
• Video recording systems
• Alarm panels
• Building automation controllers tied to schedules
• Entry and egress point sensors
• Centralized monitoring or logging platforms for each system

For each item, the team should answer three practical questions:

• Does it report timestamps?
• Does it play a role in incident investigations?
• Can it be remotely updated?

Michael also offers a useful filter for writing requirements: what breaks if this goes down? If the answer affects tenant operations or evidence, it belongs on the list. That framing keeps teams focused on operationally important systems instead of trying to document everything at once.

Three Acceptance Tests Teams Can Run This Week

The most actionable part of the episode is the maintenance and testing section. Michael lays out three lightweight checks that property and IT teams can run without turning the process into a major project.

• 15-minute cross-system timestamp comparison: trigger a known event, such as a test card swipe and a test alarm, then compare the times shown in camera footage, access logs, and alarm logs against a policy-defined tolerance.
• Boot time validation: after planned maintenance or a power cycle, confirm that systems restart with the correct time. Devices can drift or revert to defaults after reboot.
• Periodic log correlation spot checks: review a small sample of recent incidents and verify that event sequences align across systems.

The episode also notes that even simple automation can help. A basic script or scheduler that captures timestamps to a central location can expose drift before it becomes an incident response problem.

For cadence, the recommendation is intentionally manageable:

• Monthly quick checks
• Quarterly audits

What to Do When Drift Is Found

When systems drift, the operational response should include both immediate mitigation and a long-term correction. The short-term priority is to protect evidence and communicate clearly.

• Document the drift.
• Note the affected window.
• Preserve logs instead of overwriting them.
• Communicate the uncertainty window to vendors and tenants.

Then the longer-term work begins. Teams should update O&M documentation with the root cause and corrective action. The issue may come from a misconfigured device, a missing sync service after reboot, or unclear vendor responsibilities. Whatever the source, the lesson should be folded back into acceptance testing and maintenance cadence so the same problem is less likely to repeat.

The episode also suggests a useful monitoring heuristic: alert when multiple systems diverge beyond the accepted tolerance. That way, teams discover drift during routine operations instead of during an outage.

Examples That Show the Difference

Michael shares two anonymized examples that reinforce the point. In the first, a campus enforced a simple acceptance test during commissioning. Months later, a parking gate incident occurred, and the logs across the gate controller, camera, and access portal aligned within a minute. The vendor had a clear timeline and the issue was resolved the same day.

In the second example, a buildingwide power test left several controllers at default times. During a later minor outage, the mismatched timestamps made it impossible to prove whether a sensor failed before an alarm or after it. Remediation slowed down and tenants were left frustrated. That near miss led the team to add boot time validation to its checklist immediately.

Three Immediate Actions from the Episode

• Build a short inventory of timestamp-producing systems, prioritizing anything tied to tenant operations or incident evidence.
• Run a 15-minute cross-system timestamp comparison using a test swipe, a camera clip, and an alarm entry.
• Assign ownership in O&M or handover documents so time policy, check cadence, and drift handling are clearly defined.

The episode closes with a practical reminder: check who owns time, test the timeline, and preserve evidence when something goes wrong. For teams managing modern buildings, that discipline can keep recoveries cleaner, vendor response faster, and tenant disruption shorter.

Why Accurate Time Is a Building Operations Issue, Not Just a Technical Setting

In this episode of Built, Wired & Secured, the conversation takes a routine-sounding subject and turns it into a practical building operations lesson: time matters more than most teams think. Not in the abstract, and not as a protocol discussion, but in the way inaccurate clocks can slow investigations, confuse vendors, frustrate tenants, and weaken evidence when something goes wrong.

The opening scenario makes the issue easy to understand. A vendor is called to a buildingwide access problem on a Friday afternoon. Technicians arrive. Cameras show activity. Alarms recorded a sequence. Access systems have logs. But the timeline falls apart because each system is running on a slightly different clock. Instead of a fast fix, the building ends up in a multi-day investigation. Tenants stay offline longer. Teams start debating what happened instead of resolving it.

That is the real theme of the episode: timestamps seem unimportant until they turn a manageable outage into a messy recovery. The discussion stays deliberately practical. It avoids configuration minutiae and focuses instead on governance, evidence standards, ownership, and a handful of checks that teams can actually run.

Where Clock Drift Creates Real Operational Pain

Michael Harrington explains the problem from the property management side. Inconsistent time is one of those hidden issues that becomes impossible to ignore once systems fail. From a tenant perspective, it can feel like the response team is unprepared or disorganized. From an operator's perspective, it creates uncertainty in exactly the moments when clarity matters most.

Several examples in the episode show why.

Access control and camera systems are an obvious starting point. If a door controller shows 14:02, a camera clip shows 14:07, and the alarm panel records 14:05, then teams cannot confidently say who went where, what happened first, or whether one event triggered another. That slows vendor diagnosis and makes it harder to validate what tenants report.

The issue extends beyond security systems. HVAC schedules tied to time-of-day control can create occupant complaints if clocks drift. Preconditioning or setback routines may run at the wrong time, which can look like a mechanical or performance issue when the real problem is simply bad timing. In building automation, that kind of misread can waste time and send teams in the wrong direction.

The stakes rise further during forensic reviews. If a sensor goes offline around the same time as an alarm, a mismatch in timestamps can obscure whether the sensor failed before the alarm or after it. That distinction matters. It influences root cause analysis, vendor accountability, and corrective action. When the timeline cannot be trusted, remediation gets slower and less certain.

Why Ownership Has to Be Explicit

One of the strongest points in the episode is that accurate time needs a clear owner. In many properties, responsibility falls into a gray area between IT, facilities, property operations, and outside vendors. That ambiguity becomes a problem when systems from different vendors all contribute to the same incident timeline.

Michael's answer is governance. Someone should be named in O&M and handover documentation. That owner does not need to do every technical task personally, but they do need authority over the policy. The responsibility should survive vendor turnover, staff changes, and future commissioning cycles.

Operationally, he prefers IT to own authoritative time sources because IT typically manages the network infrastructure that underpins them. But facilities or property operations should own the policy that defines which systems must align to that source, how often checks occur, and how drift is handled. That shared model reflects the reality of mixed building environments: one group may manage the technical source, but another group feels the operational consequences.

The important part is not the org chart. The important part is that the policy is written down, enforced, and carried into vendor scopes. If time alignment matters to incident response, then it should exist as a documented expectation, not just tribal knowledge.

Build a Small Inventory Before You Build a Big Program

The episode recommends starting small. Teams do not need to inventory every connected device in the building. They need a short list of systems whose timestamps matter when a disruption occurs.

Michael's starting list includes access control, video recording systems, alarm panels, building automation controllers tied to schedules, entry and egress sensors, and centralized monitoring or logging platforms. That is a practical cross-section of the systems most likely to be referenced during an investigation or service event.

For each system, the team should document a few basic things. Does the system report timestamps? Does it participate in incident investigations? Can it be remotely updated? These are simple questions, but they help turn a vague concern into a prioritized policy list.

One of the most useful lines in the conversation is the question Michael asks when writing requirements: what breaks if this goes down? If the answer touches tenant operations or evidence, it belongs in the inventory. That approach keeps the effort grounded in operational impact rather than technical completeness for its own sake.

Acceptance Tests That Are Actually Usable

Many governance discussions fail because they stop at policy language. This episode does the opposite by offering concrete acceptance tests that teams can run this week.

The first is a 15-minute cross-system timestamp comparison. At a scheduled time, trigger a known event. That can include swiping a test card, generating a test alarm, and then checking the associated camera footage. Compare the timestamps across those systems and judge them against a small tolerance set in policy. The point is not perfection for its own sake. The point is to verify that the timeline is usable.

The second test is boot time validation. After planned maintenance or a power cycle, confirm that devices come back with the correct time. This matters because some devices drift or revert to defaults during restart events. That can create hidden problems that only surface during a later incident.

The third check is periodic log correlation. Pull a small sample of recent incidents and confirm that the sequence aligns across logs. This is a practical quality check because it uses real events instead of only synthetic tests.

The cadence recommended in the episode is intentionally lightweight: monthly quick checks and quarterly audits. That makes the program easier to maintain, which increases the chance it will actually happen.

What Good Operations Look Like When Drift Appears

The conversation also addresses the moment teams discover drift. The right response is both immediate and long-term.

Immediately, teams should document the drift, note the affected time window, preserve logs, and communicate the uncertainty to vendors and tenants. That matters because evidence can be overwritten and assumptions can harden quickly if no one states the timeline limits clearly.

Longer term, the root cause belongs in O&M. Was the issue a misconfigured device? A missing sync service after reboot? A gap in vendor responsibility? Whatever caused the drift should inform the next version of the checklist, the next acceptance test, or the next maintenance cadence. The goal is not just to fix one event. It is to make the environment more recoverable the next time something breaks.

The episode also recommends a simple monitoring heuristic: alert if multiple systems diverge beyond the accepted tolerance. That kind of lightweight monitoring can catch a problem before it becomes part of an outage investigation.

Two Examples That Make the Case

Michael shares two anonymized stories that show both sides of the issue. In one case, a campus required a simple acceptance test during commissioning. Months later, a parking gate incident occurred. Because the gate controller, camera, and access portal all aligned within a minute, the vendor arrived to a clear timeline and the issue was resolved the same day.

In the other case, a buildingwide power test left several controllers running on default times. Later, during a minor outage, that drift made it impossible to prove whether a sensor failed before or after an alarm. The result was delayed remediation and frustrated tenants. The lesson was immediate enough that boot time validation was added to the checklist right away.

Three Actions to Take This Week

The episode closes with three direct recommendations. First, build a short inventory of systems that generate timestamps and prioritize the ones tied to tenant operations or incident evidence. Second, run a 15-minute cross-system comparison using a test swipe, a camera clip, and an alarm event. Third, assign ownership in O&M or handover documentation so time policy, check cadence, and drift response are clear.

That is what makes this conversation useful. It does not frame accurate time as an abstract technical best practice. It frames it as part of building resiliency, operational clarity, and evidence quality. If your team wants cleaner incident reviews, faster vendor coordination, and fewer avoidable delays during recovery, this is a small discipline with outsized impact.

For listeners who want a quick starting point, the episode points to a one-page Time Sync Checklist on the Built, Wired & Secured resource hub. Listen to the full episode for the complete discussion and use it to pressure-test how your building handles time before the next incident forces the issue.