Flood Early Warning Software: What It Takes to Trust an Alert at Three in the Morning

The three in the morning decision this software actually serves

A duty engineer's phone goes off at 3:12am. A rain gauge in the upper basin has logged an intense burst, a stage sensor eleven miles downstream is climbing, and a low water crossing on the far side of the county has a school bus route over it in four hours. The decision in front of him is not academic. Close the crossing and he owns the disruption. Do not close it and he owns something worse. What he needs in that moment is confidence that the two sensors telling him this are actually working, and a way to reach the road crew, the sheriff and the emergency manager with proof that they heard him.

What he usually has instead is a base station screen with a red row on it, a phone tree in a laminated binder, and a memory of the last two times this gauge cried wolf because the tipping bucket had a wasp nest in it. That gap, between a threshold being crossed and a defensible decision being made and acted on, is the whole product. Everything else in a flood warning system is plumbing that supports it.

Problem one: your gauge network is older than any software you can buy

A typical flood control district network is a museum. Some sites transmit on legacy ALERT, a one way radio protocol that has been in the field since the 1980s and reports only when a bucket tips or a stage step is crossed. Newer sites run ALERT2, which fixes the collision and error checking problems the original had. A few remote sites go up through GOES satellite data collection because there is no radio path and no cell coverage. Somewhere there is a Campbell datalogger polled over cellular that stores tables in its own structure. And there is at least one site that only one retired technician knew how to service.

Buying a platform does not make that go away. It usually means adopting whatever subset of protocols the vendor supports well and living with a second system for the rest, which is how a district ends up with two base stations and a person whose job is watching both. The ingestion problem is not glamorous but it is the foundation, and it has to be built against the network you actually have rather than the one a product datasheet assumes.

Problem two: false alarms are what actually kills a warning program

A missed event is the fear. A false alarm is the thing that happens, repeatedly, and it is more corrosive than people expect. Every unnecessary 3am call teaches the recipients to wait and see. After enough of those, the alert that matters arrives to a group of people who have learned to check whether it is real before acting, and you have lost the minutes the system existed to buy you.

The causes are physical and knowable. Tipping buckets clog with debris, ice up, and over-report in high wind. Pressure transducers drift and go stuck, reporting a plausible constant value that no simple threshold catches. Radios produce corrupted decodes. A stilling well silts in. A stage sensor keeps reporting fine while the channel geometry it was rated against has changed after the last flood, which means the stage to discharge relationship you are alerting on is quietly wrong.

None of that is caught by a threshold rule. It is caught by validation: comparing a gauge against its neighbours, against radar derived rainfall estimates from the national mosaic products, against its own recent behaviour, and against battery voltage and transmission timing. A value that has not changed in nine hours during a storm is not a reading, it is a symptom. A system that treats sensor health as a first class concern rather than a maintenance report is the difference between an alert your emergency manager acts on and one he checks first.

Problem three: thresholds are hydrology, not a number in a settings screen

Most packaged systems let you set a rainfall depth over a duration and a stage level per gauge. That is the easy half. The part that matters is basin specific: how saturated the ground already is from the storm two days ago, how fast the stage is rising rather than where it currently sits, which upstream gauges have to trip together before the downstream response is credible, and what happens when a detention basin is already holding water from an earlier release.

Local knowledge lives in the hydrologist. She knows that the western tributary responds in about forty minutes and the eastern one takes closer to three hours, so a burst in the west with nothing in the east means something different than the reverse. Encoding that is the highest value work in the entire build, and it is also the thing that gets left as a manual judgment because the platform has nowhere to put it. Rate of rise rules, antecedent conditions, multi gauge logic and per crossing thresholds tied to specific road elevations should be data in your system, not knowledge in one person's head who will retire.

Problem four: alerting is a roster problem and nobody tracks acknowledgment

Sending a message is trivial. Knowing it landed is not. Warning programs run on rotating duty rosters, and the person on call in July is not the one on call in December. When an alert fires, you need escalation: if the primary duty officer does not acknowledge within a defined window, it goes to the backup, then to the manager, and every step is recorded. When the road crew is dispatched to barricade a crossing, someone has to confirm the barricade is actually up, because a closure that exists only in a work order is not a closure.

This is also where the public notification boundary sits. Your system should not try to be a mass notification platform. It should hand off cleanly to whatever the jurisdiction already uses for public alerting and the federal alerting gateway, and record what it handed over. Reimplementing public alerting inside a hydrologic system is a large project attached to a political risk you do not need to own.

Problem five: after the event, there is no record to learn from

Two weeks after a flood, the council wants to know what the district knew and when. The honest answer is often a screenshot folder and a few emails. A warning system that cannot replay an event, minute by minute, showing what data arrived, which thresholds fired, who was notified, who acknowledged and what actions were logged, cannot support an after action review or defend a decision that is later questioned. That replay capability is also how you tune thresholds, because tuning without evidence is guessing with consequences.

What Contrail, WISKI, AQUARIUS and the hardware vendors actually give you

OneRain Contrail is the most complete purpose built option in this space and genuinely knows ALERT and ALERT2 decoding, threshold alarms and hydrologic display. If your network is well within its supported protocol set and your alerting logic fits its configuration model, it is a reasonable buy and we would tell you so. The limit shows up when your basin logic, your duty roster rules or your integration into county operations needs to go beyond what the configuration screens allow, because at that point your operational knowledge lives inside a vendor subscription and extending it moves at the vendor's release cadence.

KISTERS WISKI and Aquatic Informatics AQUARIUS are excellent at what they were designed for, which is managing hydrometric time series for a monitoring programme: rating curves, corrections, quality coding, long term archives. They are data management systems for hydrologists working in daylight. They are not decision support for a duty officer at 3am with acknowledgment tracking and escalation, and stretching them into that role is a common and expensive mistake.

High Sierra Electronics and Campbell Scientific make field hardware, and their software exists to serve their instruments. That is not a criticism, it is a scope. Buy their hardware, and do not expect their base station tools to become your county wide warning platform.

What a custom flood warning platform has to include

Multi protocol ingestion covering ALERT and ALERT2 decode from your demodulator, satellite data collection retrieval, cellular and datalogger polling, plus external feeds for radar derived precipitation estimates and river forecasts from the national weather service. A sensor health and validation layer that scores every gauge continuously and suppresses or downgrades alerts from a sensor it does not trust, with the reason visible. A threshold engine that supports rate of rise, antecedent conditions, multi gauge combination logic and per asset rules for individual crossings and gates. Alert routing with duty rosters, acknowledgment windows, escalation and delivery evidence. A hand off to the jurisdiction's public notification and federal alerting path rather than a reimplementation of it. Task tracking for closures and gate operations with field confirmation. An operational map that works on a phone in a truck. A full event archive with replay. And redundancy that is designed rather than assumed: a second ingestion path, failover for the alerting service, and a documented test regime that runs monthly rather than after the next flood.

What this costs and how long it takes

Digital Heroes has delivered more than two thousand projects, and the shape here is consistent. A first release covering ingestion for your protocols, sensor validation, the threshold engine and alert routing with acknowledgment runs $80,000 to $170,000 over 14 to 18 weeks. A full system adding forecast integration, closure and gate task tracking, public and internal mapping, the event archive and designed redundancy runs $200,000 to $450,000 phased over 8 to 14 months.

What pushes the number up: the count of distinct telemetry protocols, because each is a real integration. Whether you need a public facing map, which brings load, caching and communications review with it. The redundancy and testing regime, which is not optional for a safety critical system and is where inexperienced estimates are always low. And how much basin logic exists only as expert judgment, because writing that down with your hydrologist is discovery work measured in weeks, not days.

When you should buy instead

Under about 15 gauges on a single vendor's hardware, buy. The packaged base station will do the job and a custom build is a poor use of capital. If your gauges are not maintained, meaning batteries, desiccant, bucket cleaning and annual calibration are behind, fix that first, because better software over unreliable sensors produces confident wrong answers faster. And if your county already runs an emergency operations platform your officials live in, check whether the right project is an ingestion and threshold service that feeds it rather than another screen nobody watches.

How to choose a developer for safety critical warning software

Ask how they would handle a stage sensor that reports a stable, plausible value for nine hours during a storm. If the answer is anything other than treating that as a suspect sensor and degrading its alerts, they have not thought about the failure mode that actually happens.

Ask what their failover story is when the primary ingestion server dies at 2am, and whether the alerting path can still fire. A team that has built operational systems answers with specifics about redundancy and monitoring. A team that has built web applications answers with a hosting provider's uptime page.

Ask how they will test. The correct answer includes injecting synthetic gauge data to fire real thresholds through the real routing into a test roster, on a schedule, forever. Ask who owns the code, the infrastructure accounts and the historical data. At Digital Heroes that is yours from the first commit, which matters here because your event archive is the record you will be judged on.

Start by pulling the last three significant events and listing every alert that fired, every one that should have and did not, and what the sensor was doing in each case. That list, not a feature comparison, is the specification for your first release.