“When the well’s dry, we know the worth of water.”
- Benjamin Franklin, Poor Richard’s Almanack (1746)
On 26 August 2026 a glacier collapsed above Langtang in Nepal. Seven minutes later the flood had already travelled 20 km. It ran 226 km to the Indian border.
The water was not the only failure. The silence was. The first alarm on the gauge network came 2 hours 43 minutes after the collapse, and by then the gauges nearest the source had gone dark while still reading normal.
We built JalNetra (जल water + नेत्र eye: the eye on the water) to close that gap. It watches every river, finds the villages the water will reach, and lets a person approve a multilingual voice warning to the village head. It runs entirely on AWS.
The 2 hours 43 minutes, minute by minute
TIME | What happened |
|---|
08:37 | Glacier collapse at Langtang Lirung |
+7 min | The flood has already travelled about 20 km |
Next | The gauges near the source go dark, still reading normal. No alarm is raised |
11:20 | First alarm on the gauge network, 2 h 43 min after the collapse |
Evening | Water crosses into India at Valmikinagar |
What JalNetra does
- Watch. 681 river points across India, checked every 3 hours against each river’s own record
- Predict. Which of 291 villages along the Gandak the water reaches, and when: now, +3, +6, +12 and +24 hours
- Decide. A person reviews the map and the advisory, then approves or rejects. Nothing is automatic
- Warn. One Hindi voice call, a spoken advisory, a 3D evacuation route and an AR arrow to the safe place
How it runs on AWS
Every stage uses a managed service, and nothing runs on a server we have to patch.
Service | Job in JalNetra |
|---|
EventBridge Scheduler + Lambda | Every 3 hours the monitor reads river forecasts and writes one snapshot |
S3 + CloudFront + WAF | The website, the snapshot and cached Hindi audio, behind managed rules and rate limits |
API Gateway + Lambda | Throttled public API, approvals and helpers |
RDS PostgreSQL + Secrets Manager | Call ledger, per-alert and daily limits, the one allowed destination number |
Amazon Bedrock (Nova Lite) | Fact-bound Hindi and English advisory drafts, always reviewed by a person |
Amazon Polly (Kajal) | The spoken Hindi advisory, cached in S3 |
Amazon Location Service | Real walking routes to the safe place |
Amazon Rekognition | First-screen check of a citizen’s flood photo |
Step Functions + SNS + SQS | After approval: wait, check, escalate. A call is never retried |
CloudWatch + CDK | Dashboard, alarms and infrastructure as code |
From a river reading to a ringing phone
- Monitor. EventBridge wakes a Lambda that scores every river point against its own 2025 monsoon, with a minimum flow so a trickle never raises a flag. One snapshot goes to S3 and CloudFront serves it
- Approve. The operator opens an alert and sees the villages, the timing and the advisory draft. Opening an alert never calls anyone. Only Approve does
- Voice and route. Polly speaks the Hindi advisory, Location Service finds the walking route, and the village head gets a link that opens the route in 3D, with an AR arrow on the phone
How good is the model? Honest numbers
The village score is a small logistic model on four things: the 72-hour peak river flow, the village’s height above the river, its height relative to its surroundings, and its distance from the river. A village is flagged when the probability reaches 0.25
flag a village when P(flooded) >= 0.25
inputs: ln(Q72max / 4000), height above river, height vs surroundings, distance
We tested it against real Sentinel-1 radar flood maps from the 2026 event, leaving each radar date out when training:
Result | Value |
|---|
Flooded villages caught | 56% and 66% (two radar dates) |
Ranking skill (AUC) | 0.72 to 0.75 (0.5 is a coin flip) |
Flagged villages that were really flooded (29 Sept) | 36%, with 70 false alarms |
This is an early-warning screen, not a guarantee. Radar only sees open water, so flooding under trees and from local rain is missed. We would rather say that plainly than oversell it.
Safety by design
A warning system that can phone people has to be hard to misuse.
- No call is ever automatic. A person approves every one
- A call can reach only the configured demo phone. No route accepts a phone number
- One attempt per alert, a cooldown, 3 calls per session and a daily cap, all enforced on the server
- “Dispatched” is never shown as “answered”. Failed or unknown outcomes stay locked
- Exercise data is labelled EXERCISE everywhere and kept apart from real incidents
Loading article