Blog · CityWatch
After the flood, the review should be a replay, not an argument.
Every bad monsoon evening ends in a meeting. Too often that meeting is about memory and blame. It could be about minutes and evidence instead.
The meeting after every bad evening
The morning after a city floods, the questions are always the same. When did we know? Who was told? Were the pumps running? Was that drain cleaned? The answers usually come from memory, from phone call logs, from a register that says the desilting was done, and from the ward officer who was on the ground and is now exhausted.
Nobody in that room is acting in bad faith. But when the record is a collection of recollections, the review drifts towards whoever tells the most convincing story. The city engineer's line we hear in almost every first conversation sums it up: the register says the drain was cleaned, and the water says otherwise.
Why reviews turn into arguments
The data a city needs mostly exists already. Rain gauges, channel levels, pump status, citizen complaints and crew movements all report somewhere. The problem is that they arrive on different clocks, to different people, in different formats. A review that tries to stitch them together afterwards cannot be precise about the one thing that matters: what was knowable, and when.
| Question in the review | Typical source today | Why it is disputed |
|---|---|---|
| When did the rain cross a dangerous rate? | A gauge report pulled later | Nobody was watching it against the channel level at the time |
| Were pumps running? | The operator's word | Pumps are assumed running unless someone reports otherwise |
| When did citizens report it? | Paper or phone complaints | Tickets were created days later |
| Was the drain cleaned? | A register entry | A signature is not proof of work |
What a replay changes
A replay puts every event on one timeline, minute by minute, with its source and its owner. In CityWatch every event carries a source, a timestamp and an owner, from the first rain cell to the closed ticket, so the whole evening can be played back: when the rain rate and channel trend crossed the alert threshold, which wards the proposed alert covered, which pumps were running, offline or showing no telemetry, when the first WhatsApp complaint arrived and which crew was routed to it.
That shifts the review from "who is to blame" to "where did the minutes go". If the alert was proposed with time to spare but nobody acted, that is a process gap at the control room. If the alert came late because a gauge had gone silent, that is a maintenance gap. If the drain segment had no geotagged before-and-after photos, the desilting claim was never proven in the first place. Our guide on desilting proof of work covers that last point in detail.
A replay is fairer to the people on the ground
It is easy to see a replay as a tool for catching people out. In our view it does the opposite. Ward officers and crews are often blamed for floods that started upstream, or for slow responses to complaints that reached them late. A replay shows what they knew and when they knew it. A crew that arrived quickly after being assigned is protected by the record, not exposed by it.
How we would run the review
- Pick the worst event of the week, not the average one.
- Replay it from the first rain cell, and mark the moment the alert threshold was crossed.
- Measure the warning window you actually had, and how much of it was used.
- List every silent sensor and every unproven claim of work.
- Agree one change for before the next storm, with an owner.
The daily report can be drafted from the same record, with every source linked, and so can any annexure needed for a court or an audit, which saves the team from rebuilding the evening twice. For the wider argument about acting before rather than after, see reactive vs early-warning flood response, or browse the CityWatch guides.
Questions
What is a flood after-action review?
A structured review after a flooding event that establishes what was known, when, and what was done, so the city can change something before the next storm.
Why replay a flood event minute by minute?
Because gauges, pumps, complaints and crews report on different clocks. A replay on one timeline shows where the warning minutes went, instead of relying on memory.
Does a replay just assign blame?
It often protects field staff, by showing when they were actually informed and how quickly they responded.
See it on your own data. CityWatch — Warn before the street floods. Book a 30-minute working session with an engineer.