Storm reporting often arrives before the operating record is complete. A Guardian report on the Arizona storms, credited to the Associated Press, describes how "Violent storms overnight" knocked over utility poles and carried heavy winds through central Arizona, with trees falling onto homes and a possible tornado reported in one community. The storms moved through the state overnight into Thursday. For a municipal water system, that description raises a practical question: when the power dropped, what did the utility's own records show, and how well do they agree with one another?
The source material does not say which water systems were affected, whether any service was interrupted, or how long any outage lasted. Those gaps are normal for early coverage, and they are the reason a water utility should build its own timeline from its own records rather than inferring it from the news.
Why one storm produces several outage records
A pole failure does not appear in one place. It shows up first as a loss of supply to a facility, then as a stopped pump or a failed generator transfer, then as a drop in pressure at the distribution level, and finally as calls from customers who notice dry taps or low flow. Each of these records starts from a different source, a different clock, and a different threshold for what counts as an event.
A supervisory control alarm logs when a device changes state, but only if the telemetry path stayed powered and connected. A customer contact entry logs when someone picked up the phone or submitted a form, which can lag the actual interruption by hours. A dispatch record logs when crews were assigned, not when the fault occurred. Timestamps may come from different time sources, and some entries are batched or keyed in after the fact. None of these records is wrong by design. They simply answer different questions.
What the reconciliation should answer
Before any public notice goes out, the reconciliation should answer a short set of questions in order. First, when did the power supply fail at each pump station, well field, and treatment site, and when was it restored? Second, did standby generators start, transfer load, and hold for the full interval, or did any run down? Third, when did pressure fall below the minimum the system is designed to maintain in each pressure zone, and when did it recover? Fourth, when were any conservation, boil-water, or other customer notices issued, and what trigger did they rely on? Fifth, do customer reports cluster in the same zones as the telemetry, or do they point to areas the system's records do not show?
The answers rarely line up cleanly on the first pass. That is useful information, not a failure of the process. A gap in telemetry during the outage may mean a radio or cellular modem lost power along with the site. A reservoir level that barely moved may hide a short interruption that drained a small zone and refilled quickly. A cluster of customer calls outside the telemetry zones may indicate that the pressure zone map does not match the physical network, which is a documentation problem rather than an operations one.
Where the records disagree, and what that does not prove
Disagreement between records does not by itself show that water was unsafe or that service was lost. It shows that the record is not yet complete enough to support a confident statement. The tradeoff is real. A reconciliation that waits for every late entry can delay a public notice that customers need now. A notice issued on the first pass of the logs can later be contradicted by the telemetry, which damages trust more than a slower, accurate statement would have. The practical approach is to issue a notice scoped to what is confirmed, label what is still under review, and update it when the reconciliation closes.
Some of the uncertainty also sits outside the water utility. Poles and power lines may belong to a different owner than the one supplying the water system's electrical feed, and the outage map that the water utility consults may come from that owner. Access to that data may depend on an agreement that should be in place before a storm, not requested during one.
Setting the rule before the next event
A utility can reduce the reconciliation burden by fixing a few rules in advance. Name one clock source as the incident reference, and convert every other timestamp to it. Keep the raw telemetry export separate from the narrative summary so that reviewers can check the summary against the data. Record for each asset the time of the supply loss, the time of restoration, and the state of backup equipment. Mark every entry added after the event, with the name of the person who added it and the reason. Define in advance the threshold that triggers a public notice, such as a confirmed pressure loss in a named zone, so that the decision does not depend on how the storm happened to look at two in the morning.
None of this removes uncertainty from a storm. It separates the uncertainty that cannot be avoided from the uncertainty created by records that were never designed to be read together. For a utility, that separation is the difference between a timeline that holds up under review and one that has to be corrected in public.