A global disaster alerting system exists because most disasters are reported slowly and unevenly. An earthquake is detected by seismic networks within minutes, but who was affected, and how badly, is a question that takes days to answer properly through official channels. In the gap between the two, decisions get made anyway: whether to activate a response team, whether to check on a facility, whether a supply route is likely to be cut.
GDACS, the Global Disaster Alert and Coordination System, is the best known open feed built for that gap. It aggregates automatic detections of natural hazards, earthquakes, tropical cyclones, floods, volcanic activity, drought and wildfire among them, and publishes them with an automated estimate of likely humanitarian impact and a machine readable geometry describing where the event is.
It is genuinely useful and it is routinely misread, mostly because of one property: the shapes it publishes are models of where a hazard could plausibly have effects, not observations of where it did. Everything below builds on that distinction.
What the system actually provides
The mechanism explains both the speed and the limits. The system does not observe disasters. It listens to upstream scientific sources that observe hazards, seismic networks for earthquakes, meteorological agencies for storms, hydrological models for floods, and applies a calculation on top. Three properties follow directly.
That calculation combines a physical description of the hazard, such as magnitude and depth for an earthquake or wind speed and track for a cyclone, with static exposure layers describing what is in the way: population distribution, and in some cases infrastructure and vulnerability indicators for the country involved. The output is a score, an alert level, and a set of geometries.
- It is automatic. There is no analyst deciding whether an event matters, so alerts appear fast and appear for events that will turn out to be unremarkable.
- It is hazard driven, not impact driven. The trigger is a measurement of a physical process. If a hazard occurs where the physical measurement is weak but the local vulnerability is extreme, the automated estimate can understate what happens next.
- It is global and uniform. The same method runs everywhere, which makes events comparable to each other and makes none of them locally precise.
The feed is published in formats meant for machines: RSS and GeoRSS variants, and CAP, the Common Alerting Protocol, which is the standard container used for public warnings across many systems. That machine readability is why it turns up inside so many dashboards and, more recently, inside so many agent tool chains.
Alert levels and what they encode
Alerts are graded on a small colored scale, conventionally green, orange, and red, where green marks an event detected but not expected to require international response, orange marks a moderate expected impact, and red marks a severe one.
Three things about that scale matter in practice.
It encodes expected humanitarian impact, not hazard severity. A large earthquake in a sparsely populated desert can carry a low alert level while a smaller one under a dense city carries a high one. People who read the level as a measure of the physical event will find it inconsistent, because it is not measuring that.
It is calibrated for international coordination. The implicit question is whether an event is likely to exceed national response capacity, which is a different question from whether a specific asset was affected. An orange alert can coexist with total destruction of one particular village, and a red alert can coexist with a specific facility being untouched.
It changes. Early estimates are based on early hazard parameters, and those get revised. Earthquake magnitude and depth are refined as more stations report. Cyclone tracks are updated continuously. An alert that was orange at first detection can become red, or the reverse, and any system that stores the first value and never revisits it will be confidently out of date. Consuming the feed means consuming updates, keyed on the event identifier, and keeping the history rather than overwriting it.
The single most important thing: the extents are modeled
When an event is published with a geometry, that geometry is almost never an observation of the hazard's true footprint. For an earthquake it is typically a set of concentric zones derived from a ground motion model: given magnitude, depth, and location, physics and empirical relationships predict how shaking attenuates with distance, and the zones are contours of that prediction. For a cyclone it is a track with wind radii, again modeled from the storm's parameters. For a flood alert it may be a coarse area associated with a river basin or an administrative unit.
Real hazard footprints are not smooth. Shaking is amplified by soft sediments and reduced on hard rock, so damage patterns follow geology as much as distance. Flooding follows terrain, drainage, and the state of embankments, so a flood extent is a highly irregular shape that hugs low ground and can leave land a few meters higher completely dry. A cyclone's damage concentrates where the wind field, the coastline geometry, and the surge interact.
None of that local structure is present in the published extent. What is present is a smooth, defensible, fast approximation. Worse, the geometry is often reduced further downstream. A polygon becomes a bounding box, because bounding boxes are cheap to index and easy to query. A bounding box around a curved cyclone track can include enormous areas the storm never approached. If that bounding box is then used to select assets, everything inside it inherits an association it does not deserve.
The correct mental model is that an extent answers "where is it worth looking" and never answers "where was it affected". Systems that keep those two questions separate produce useful output. Systems that conflate them produce confident nonsense, and the nonsense is more dangerous than silence because it looks like analysis.
Latency, and what happens inside it
Latency has several distinct components, and they behave differently by hazard type.
Detection latency is the time for the underlying science to register the event. For earthquakes this is short, since seismic networks report quickly. For floods it can be long, because a flood is a process rather than an instant and its onset is defined by thresholds being crossed. Processing latency, the time to run the impact estimate and publish it, is usually small. Revision latency is the long tail and the one that matters most: the first published estimate uses the first available hazard parameters, and refinement continues for hours or days.
There is also a distribution latency that belongs to the consumer, not the source. A cache with a long time to live, a polling interval measured in tens of minutes, a queue that backs up: all of these add delay that the source cannot see and the user cannot distinguish from source delay. Any interface that shows event data should show when it was fetched and when the source last updated it, because the difference between those two timestamps is exactly the amount of staleness the consumer introduced.
For slow onset hazards the framing shifts entirely. Drought has no moment of occurrence, so alerts describe an evolving condition, and treating them as discrete timestamped events misrepresents the phenomenon.
Monitoring versus response
The single clearest rule in this domain: an automated global alert feed is advisory, and it is never a substitute for official warnings issued by the authority responsible for a place.
Official warnings have properties this data does not. They come from bodies with legal responsibility and local knowledge, they carry instructions rather than descriptions, they reflect ground truth arriving from local sources, and they are the basis on which evacuation and emergency response are coordinated.
A global aggregation is a monitoring layer. It is well suited to noticing that something happened somewhere relevant, prioritizing which of several situations deserves attention first, keeping a consistent historical record across countries, and triggering an internal process such as contacting a site manager or querying a local source.
It is not suited to telling anyone whether to evacuate, whether a specific building is safe, or whether a specific road is passable. Any product built on this data should say so in its interface rather than in a footer, and should link onward to the responsible national authority wherever it is presenting a specific place.
That is not legal caution alone. It is a description of what the data can support. A model of expected shaking cannot tell you about one structure, because the variance between structures at the same shaking level is enormous and depends on construction, age, and soil.
Joining events to exposure, and the false precision it creates
The obvious next step is to intersect an event extent with something valuable: population, buildings, roads, health facilities, a portfolio of sites. This is the operation that turns an alert into an exposure estimate, and it is also where the largest errors get manufactured.
The arithmetic is trivial. The interpretation is not, because the result inherits every weakness of both inputs and presents them as a clean number.
Consider the failure modes stacked in a single such number.
- The extent is modeled and smooth, so the selection is approximate at the boundary and possibly wrong in the middle where local geology or terrain dominates.
- If the extent was simplified to a bounding box, the selection includes areas with no plausible relationship to the event.
- The exposure layer has its own coverage bias. Building and road datasets are less complete in poorer and more rural areas, precisely where vulnerability is often highest, so a count of affected buildings tends to understate exposure exactly where it matters most.
- The exposure layer has its own currency problem. A building footprint dataset compiled a year ago does not include the settlement built since.
- Population grids are themselves models, redistributing census counts using ancillary data. Intersecting a modeled hazard extent with a modeled population surface produces a modeled number twice over.
The characteristic symptom of all this is false precision. A pipeline that outputs "184,326 people exposed" is reporting the resolution of its arithmetic, not the accuracy of its answer. Every digit after the first two is manufactured.
Presenting an exposure estimate honestly
Honest presentation is mostly a matter of refusing to let the format imply more than the method supports. A few rules carry most of the weight.
Round to the precision the method can defend. Report an order of magnitude or a banded range. "Roughly one hundred thousand people, plus or minus a large factor" is a more accurate statement than any exact figure, and readers who need the exact figure are exactly the readers who should be told it does not exist.
Put the caveat before the number, not after it. A caveat below a large figure loses to the figure every time. If the extent is a modeled envelope, the sentence introducing the number should say so, in the same breath.
Name the inputs and their vintage. Which hazard extent, which exposure layer, when each was last updated. This is what allows someone to disagree with the estimate intelligently, which is the whole point of publishing a method.
Separate what was joined from what was not. If a portion of the exposure data was missing, unavailable, or failed to load for part of the area, that fact must survive to the output. A count computed over partial data and presented as a total is the most common quiet lie in this entire field. It is better to report "counted over the 60 percent of the area with coverage" than to report a total that silently means the same thing.
Report the query, not just the answer. If the operation was "assets whose point falls inside the modeled orange zone", say that. The reader can then judge whether that operation means anything for their question, which they cannot do from a number alone.
Never suppress zero results into silence. If no assets fall inside the extent, that is a result, and it should be reported as such rather than as an empty panel that looks like a loading failure.
A worked case
A logistics operator holds sites across an island region and wants to know each morning which ones need attention. A weak implementation polls the feed, takes each event's bounding box, selects sites inside it, and emails a list. It raises alarm for sites hundreds of kilometers from any actual hazard, and after two weeks people stop reading the email. The failure is not technical. The system worked as designed, and the design implied observation where there was only a model.
A defensible implementation keeps the same feed and changes the framing. Events are matched against sites using the most detailed geometry available rather than a box, and the match produces a category rather than a verdict: inside the modeled severe zone, inside the modeled moderate zone, or near the boundary. Each match states the alert level, the time of the last source update, and the fact that the zone is modeled. Matches are ranked by modeled severity combined with site criticality, so a small warehouse and a distribution hub are not equivalent, and the output for each site is a recommendation to verify through a local channel with the responsible national agency linked. Events that update are re-evaluated rather than frozen at their first value.
The second version is the same join. It differs in that every number it shows is qualified by how it was produced, and the action it recommends is verification rather than conclusion. That is what makes it survivable when an event turns out worse than modeled, and it will, in both directions.
The honest limit
The most useful thing an automated global alert feed does is reduce the time between something happening and someone competent looking at it. That is a real contribution and it is worth building on.
What it cannot do is tell anyone what happened. A modeled envelope plus a modeled exposure surface produces a modeled estimate, and no amount of downstream processing converts that into observation. The value is in triage, and triage is honest work as long as it is labeled as triage.
The test to apply to any product built on this data is simple. Read the output as though a person will act on it without reading anything else, because someone will. If the interface makes the reader believe a specific place was affected, when the underlying data only supports the claim that a place is within a region where effects were plausible, the product is wrong regardless of how correct the code is.