Infrastructure
The Outage Log Is the Town's Memory: Recording Each Water Interruption Before the Questions Arrive
A short, dated record of every service interruption, whatever caused it, turns a bad day into information a board can actually use.

Every water system in the Midwest has bad days, and most of them end the same way: the water comes back, the crew goes home, and nobody writes down what happened. A few weeks later, a board member asks how often the north side lost pressure, or a resident wants to know whether the boil notice last spring was the first of its kind. Memory is a poor record for those questions. A written outage log is a plain tool that answers them.
The reason to start now has less to do with any single crisis than with how wide the range of causes can be. A recent interview published by Circle of Blue, written by Brett Walton and featuring Peter Gleick, examines the troubling rise in water violence. Its summary notes that for people in a war zone, "Your water supply could be cut." That situation is far from anything a Midwest town faces, but it makes a useful point for local record keeping. An interruption can start with a stuck valve, a power failure, a contractor's mistake, or a deliberate act, and the first hours often look identical. A log that records only the outcome cannot tell those apart later. You can read the full Circle of Blue interview with Peter Gleick for the wider context.
What each entry should hold
A useful entry is short. Write down the date, the time the problem was first noticed, the time it began, and the time service returned. List the streets, zones, or addresses affected, using the names your crew already uses on the system map. Note the apparent cause in plain words, even if the answer is "unknown at the time," and mark whether a pressure drop, a boil notice, or a shutoff followed. Record the name of the person who took the call and the name of the person who authorized repairs. Tie each entry to the system's own records, such as work orders and pump run logs, so that a later reader can check it.
Keep conclusions out of the first draft. The log is a record of what the operator saw, and an explanation can follow in a separate note once the crew has finished. Mixing the two makes both harder to trust, especially when the first explanation turns out to be incomplete.
Where the log lives
A paper binder in the plant office works for a very small system, but it fails when the plant itself is the thing that is down. Many towns keep a shared spreadsheet or a simple form that the operator fills in on a phone, with a printed copy included in the monthly board packet. Whichever format you choose, decide before the next event who has edit access, who reviews entries, and where the file is backed up. Who owns the record matters as much as the record itself.
Homes on private wells face a different version of the same problem. A household on a well has no operator log at all, so its own notes on water color, pressure changes, and shutoffs become the only written trail. Keeping those notes in the same dated format makes them easier to share with a local utility or a county office if they are ever needed.
Reading the log later
Once the log has a few months of entries, patterns become visible. Repeated pressure drops on the same street may point to a valve, a main with a history of breaks, or a pump cycling more often than it should. Clusters of interruptions during storms may point to the power supply feeding the plant. A single unexplained shutoff proves little, but a record that shows the same unexplained event several times gives a board a concrete reason to ask for a closer look. That is the practical value of the record: it turns a general worry into a dated question that a utility can answer.
National reporting can supply context, but it cannot tell a town what happened on its own pipes. Only the local log can answer that. Keep the two kinds of information separate in your minutes, and label each clearly so readers know which is which.
Start before the next event
The best time to start an outage log is on a quiet afternoon. Pick the format, name the keeper, and enter any interruptions you can document from existing work orders, with their original dates. Then each new event adds to a record rather than starting an argument. A small system does not need expensive software to do this well. It needs dates, places, and a habit of writing things down before the story changes.