41 minutes: why an alert system is not an early-warning system.

Dear {{ first_name | reader }},

At 08:32 on 26 August, the floodwater reached the Nepal-Tibet border crossing. At least four monitoring stations were destroyed. At 08:58, Nepalese warning specialists learned something had happened. At 09:13, the mobile alert went out.

Forty-one minutes.

More than 1,000 people are now confirmed dead across Nepal and Tibet, with thousands still missing. Search and rescue efforts are still under way as I write this, and many families are still waiting for word of relatives who haven't been found.

I want to hold that for a moment before I make any analytical argument, because what follows is about systems, and it should not be mistaken for a suggestion that the people who responded to this disaster did not work hard or care deeply.

A Reuters investigation, reported by Saurabh Sharma, Devjyot Ghoshal and Sarita Chaganti Singh, has given us something rare in disaster analysis: an almost minute-by-minute record of what the system had available, and when.

That record points to something structural. And it sits well outside any single organisation's control.

I've gone back and forth on whether to publish this while search and rescue is still under way. What decided it was this: the gaps that caused those 41 minutes are the kind that get studied once a story has left the headlines, then forgotten by the time the next one happens.

I'm not treating what happened here as a case study. I'm making an argument for closing the same gap somewhere else, before it costs someone else those same 41 minutes.

Crisis communicators spend a great deal of time on alerts: which channels to use, how to write a message at a Grade 6 reading level, whether cell broadcast outperforms SMS at scale. These are real questions, worth answering.

But they are questions about the last three metres of a much longer supply chain.

That supply chain looks like this:

detection → data sharing → interpretation → decision → warning → action

Most communicators own one link — the warning. The others belong to hydrological agencies, bilateral data agreements, satellite operators, telcos, national meteorological bodies, and cross-border diplomatic relationships that may or may not be functioning on a Tuesday morning when a glacier collapses above a river valley.

Nepal had apparently been seeking greater access to Chinese glacier, water-level and hazard-monitoring data for months before 26 August. China says information was shared appropriately. Experts note the glacier collapse was genuinely difficult to predict. I'm not interested in assigning blame here, on either side of the border, and nor should anyone reading this. I'm interested in the architecture.

If your warning depends on data you do not receive in time, the quality of your message is irrelevant.

The 41 minutes between 08:32 and 09:13 is not a communications failure. It may be close to the physical minimum given what was available. Alerting faster than your detection system can detect is not possible. Data does not cross a border when the sharing agreement is incomplete. A destroyed monitoring station sends no signal to interpret.

The IFRC reported difficulty communicating with its own teams during the response because of limited phone signals in affected areas. None of that reflects poorly on anyone who was there. It reflects how much infrastructure a disaster of this size can take down in a single morning. The infrastructure that carries the warning message was itself a casualty of the event.

Crisis communicators design systems for normal conditions and test them under normal conditions. The event that arrives is abnormal by definition. Sensors fail. Networks drop. Decision-makers are unreachable. The chain you mapped in the planning document is not the chain that exists at 08:58 on the morning in question.

Nepal now intends to seek Chinese hydrological data at ten-minute intervals. That is a meaningful improvement. But it is still a detection and data-sharing fix. It addresses the first two links.

What about the others?

Most crisis communication exercises I see are message-drafting exercises with a stakeholder map attached. Teams practice what to say and who to call. Almost none test what happens when the upstream information supply chain is broken.

What is your detection baseline? Where does your early-warning data come from? Which of those sources are outside your control? And what is your protocol when they go silent? Who makes the decision to issue a warning when the picture is incomplete? What is the threshold? Who owns it?

These are not questions for the national meteorological agency. They are questions for anyone who might one day need to tell people to leave.

What happened on 26 August will be studied for years. It will generate reports, recommendations, probably new diplomatic protocols for transboundary data sharing. Most of those recommendations will be correct.

What I hope does not happen is that communicators read those reports and file them under hydrology — a technical problem for technical agencies, nothing to do with the message-drafting function. The supply chain argument runs straight through the communications office.

Map the supply chain. Not the communications plan. The information supply chain. Start at detection and work forward. At each link, ask: who controls this? What is the failure mode? What does our system look like if that link is gone?

Then exercise it. Not the message-drafting part. The broken-chain part.

The 41 minutes between the flood hitting the border and the mobile alert going out are 41 minutes that belong to the whole system. Most of those minutes were not in the communicator's hands.

What any individual did or didn't do that morning is not the point, and we shouldn't pretend to know. The point is whether your system — right now, before the next event — has been mapped, tested, and exercised all the way back to detection.

None of this brings back anyone who died on 26 August, or shortens the wait for the families still searching for someone who hasn't come home.

What it can do is make sure that somewhere else, the next time a river rises without warning, there's more than 41 minutes to work with. That's the only reason worth writing any of this down.

An alert system is not an early-warning system. Knowing the difference is the work.

_{Transparency & Disclosures}

_{AI Transparency: In alignment with EU AI Act requirements, please note that AI technology was used in the research, drafting, and/or image generation for this edition. All strategic analysis, professional opinions, and final editorial oversight are conducted exclusively by the author. Affiliate Disclosure: Some links in this briefing may be affiliate links. I only recommend tools and services I use personally or have vetted for professional efficacy. Professional Advice: This newsletter is for educational and informational purposes only and does not constitute legal or professional crisis management advice. © 2026 RiskComms FZCO. All rights reserved.}