GDACS Global Disaster Alerts - past the 100-event cap

Earthquakes, tropical cyclones, floods, volcanoes, droughts and wildfires from GDACS, the Global Disaster Alert and Coordination System run jointly by the United Nations and the European Commission. One row per event, 56 fields, straight from the source.

The reason this Actor exists is a number. A single GDACS query returns at most 100 events, no matter how wide a window you ask for. Ask for six years and you get 100. Ask for a year and you get 100. Nothing in the response says it was cut short - no total, no next page, no flag. A pipeline built on the plain endpoint quietly stops being complete the moment the world gets busy.

This Actor splits the request by alert level, by hazard type and by date window, halving each window again whenever it comes back full, and merges the results by event id. You get the events, not the first hundred of them.

---

What exactly does this Actor collect?

Every event GDACS publishes, in six hazard types:

Code	Hazard	What the severity number means
EQ	Earthquake	magnitude, unit M
TC	Tropical cyclone	maximum wind speed, unit km/h
FL	Flood	GDACS flood magnitude
VO	Volcano	GDACS volcanic index
DR	Drought	affected area, unit km2
WF	Wildfire	burnt area, unit ha

Each event carries the GDACS colour - Red, Orange or Green - plus the numeric alert score behind that colour, the countries affected, coordinates, start and end dates, the upstream feed that produced it, and the link to the GDACS report page a human would read.

GDACS has no separate tsunami type. Tsunami information arrives inside earthquake events; a query for eventlist=TS comes back empty.

Why does one GDACS query return only 100 events?

Because that is the cap, and it is not documented. Measured on 2026-09-11 with plain HTTP requests, no key and no browser:

Window asked for	Events returned
2026-08-01 to 2026-09-12	20
2025-01-01 to 2026-09-11	100
2020-01-01 to 2026-09-11	100

Six years and twenty months give the same answer as each other, and that answer is exactly the cap. The live test suite in this repository asserts both halves of that: a wide window must come back at exactly 100, a six-week window must come back below it. If GDACS ever raises the cap, that test fails and the number in this README stops being true out loud rather than silently.

What happens if you simply ask GDACS for all three alert levels?

You lose the important ones. This is the trap that costs data rather than time, and it is worth reading twice.

Left alone, GDACS returns Red and Orange events only - Green is absent unless you name it. The obvious fix is to pass all three levels at once. Measured on the window 2026-08-01 to 2026-09-12:

Request	Events returned	Colours present
no alertlevel parameter	20	Red, Orange
alertlevel=Green;Orange;Red	100	Green only
alertlevel=ALL	0 (empty body)	none

Asking for everything returns a full page of green events and drops every red and orange event in the window. The naive "give me all levels" call is strictly worse than the default one. And ALL, the value a dropdown would naturally send, returns an empty HTTP body - not an empty collection, an empty body, which crashes a JSON parser that was not expecting it.

This Actor therefore queries each alert level separately and merges. That is also why the level selector defaults to Red and Orange: those are the events an operations desk acts on, and adding Green multiplies the volume rather than the signal. Turn Green on when you are building an archive.

How much does the splitting actually recover?

Measured over 2026-01-01 to 2026-09-12, with tools/measure_cap.py:

• one plain query over the whole period returns 63 events, all Red or Orange;
• the same query asking for all three levels returns 100 - the cap - and every one of them is Green;
• nine month-by-month queries over that period return 900 rows, 776 unique events: 613 wildfires, 70 floods, 60 earthquakes, 25 droughts, 6 cyclones, 2 volcanoes. All nine of those monthly queries were themselves sitting at the cap, so 776 is a floor, not a total;
• the Actor's own walk halves each full window again, and reports every query it spent and every split it made.

Narrow it to one hazard type at one level and the gap is starker still. Green earthquakes over 2026-08-01 to 2026-09-12, measured by the live test suite on 2026-09-12: 704 events collected in 21 queries with 10 window splits, against 100 from a single query. Seven times the data for twenty extra requests.

The run report names the arithmetic so you never have to trust this paragraph: walk.queries, walk.splits, walk.found, walk.duplicates and walk.cap_per_query. Set compareWithSingleQuery to true and the report also records what one plain query would have returned over your exact window, so the comparison is made on your data rather than on ours.

If a single day of one hazard type at one alert level still comes back full - which can happen on a heavy wildfire day - the day is listed in walk.truncated_days and logged as a warning. There is nothing left to split at that point, and saying so is better than pretending the result is complete.

What do you get for each event?

Fifty-six fields. The ones that matter most:

Identity. event_id and event_type form the key; episode_id rises every time GDACS re-issues its assessment, which is the cheapest possible signal that a situation moved. glide carries the GLIDE number - the cross-agency humanitarian identifier such as DR-2026-000153-BLZ - which is how the same disaster is matched across ReliefWeb, EM-DAT and UN reporting. source and source_id name the upstream feed and its own identifier, so an earthquake row carries the USGS event id (us7000tgpu) and joins straight to USGS data.

Severity. alert_level, alert_score, episode_alert_level and episode_alert_score, plus severity, severity_unit and the sentence GDACS writes itself in severity_text ("Magnitude 4.7M, Depth:61.088km").

Place. country, iso3, latitude, longitude, bbox, and affected_countries - the full list with ISO2 and ISO3 for every country GDACS attaches to the event, not just the one it is centred on. Country filtering uses that full list.

Time. from_date, to_date, date_modified, and the is_current flag GDACS uses for "still going". Dates come out in one shape across every row.

Links. report_url for the human page, plus the API links for the event card, the polygons, the media feed and the GDACS news feed.

What does the event card add?

With includeDetails on - the default - the Actor spends one extra request per event on the GDACS event card and fills in what the list endpoint does not carry:

• magnitude and depth_km for earthquakes, as numbers rather than text;
• population_exposed and population_exposed_text - GDACS's own rapid estimate of how many people were exposed to strong shaking, for example 23 526 people, worded by the source as "20 thousand (in MMI>=VII)". The intensity band travels with the text because GDACS varies it between events. This is the source's figure, not a guess made by measuring the distance to the nearest entry in a bundled list of cities;
• shake_population from the ShakeMap pass once it has run;
• episode_count, which tells you how many times GDACS has revised the event;
• map imagery: overview_map_url, thumbnail_url, population_map_url, rain_map_url.

Turn includeDetails off for the fastest possible listing.

What are the affected-area polygons?

GDACS publishes real geometry for most events: cyclone tracks, flood extents, shaking contours, drought areas. Switch on includeGeometry and each row gets a polygons array of GeoJSON geometries, each labelled with what it represents. It costs one more request per event and makes rows considerably larger, which is why it is off by default.

How do I watch my own sites?

Pass a list under assets:

[
  {"name": "Manila DC",   "lat": 14.60, "lon": 120.98, "radiusKm": 300},
  {"name": "Kaohsiung port", "lat": 22.62, "lon": 120.28, "radiusKm": 500}
]

Every event with coordinates is measured against every site with the haversine formula. Rows come back with nearest_asset, nearest_asset_km, asset_exposure and the full asset_matches list, nearest first. Exposure bands are stated rather than implied: critical within a quarter of your radius, high within half, moderate within the radius. Sites outside their radius are dropped from the list, the event itself is kept.

No geocoding service is involved and no city table is bundled, so the same input always produces the same number. If you want a different definition of "close", change the radius.

How do I only pay for what changed?

Turn on onlyNew. The Actor keeps a record of what it has already delivered in a named key-value store, which survives between runs, and skips events whose alert level, episode, severity, end date and ongoing flag are all unchanged. Every row is tagged NEW, UPDATED or UNCHANGED.

This matters more here than in most sources, because disasters are long-lived. A drought measured on 2026-09-11 had been running since 21 April - 143 days. Without memory, a daily monitor pays for that one event 143 times.

Deliberately excluded from the change fingerprint: date_modified. GDACS touches it whenever a model re-runs, so including it would mark nearly every event as updated every day - which is exactly the cost the mode exists to avoid. If you would rather have a complete snapshot each run, set emitUnchanged and unchanged rows come back too, correctly tagged.

The order is always deliver first, remember second. A run that dies halfway through has remembered no more than it actually delivered, so the next run picks up the remainder instead of skipping it. The lifecycle test kills a run mid-push and asserts exactly that.

How do I get a Slack or Discord message?

Put an incoming webhook URL in webhookUrl and pick a floor with webhookMinAlertLevel. One message per run, listing the alerts that reached the threshold with the GDACS report link for each, red first. A webhook that fails is recorded in the run report and never fails the run - data first, notification second.

What does the run report tell me?

It is written to the key-value store under REPORT:

• walk.queries, walk.splits, walk.found, walk.duplicates, walk.failed_windows, walk.truncated_days, walk.cap_per_query. The duplicate count is normally large and that is correct: GDACS selects events that overlap the window, so a six-month drought is returned by every window that touches it and is merged by event id;
• pushed, by_type, by_alert_level;
• filtered_out - how many rows each filter removed, by reason, before anything was charged;
• changes - the NEW / UPDATED / UNCHANGED tally in incremental mode;
• webhook - whether the notification went out;
• single_query_would_return, if you asked for the comparison.

How is it priced, and what is it going to cost me?

Pay per result: $0.99 per 1,000 events, plus Apify's usual start event. Filters run before anything reaches the dataset, so a run that fetches 400 events and keeps 12 charges you for 12. maxItems is a hard stop on both rows and spend. If you set a per-run spending limit in Apify, the Actor reads it at start and stops itself at that number of events instead of running on at the developer's expense.

How fast is it?

GDACS answers very unevenly. The same default run - twelve window queries and fourteen event cards - finished in 28 seconds on one attempt and 175 seconds on another, measured on the Apify platform on 2026-09-12. Per request, the event card takes about 3.6 seconds and the polygon endpoint about 4.2 seconds.

Both stages therefore run four at a time: the window queries across hazard type and alert level, and the event cards within each batch. Four is what keeps a hundred-event run inside a couple of minutes even on a bad day, and is still polite to a public service. Nothing is fired off all at once - the walk goes a batch at a time, so a request covering years does not have to hold the whole result in memory.

How does this compare with the other GDACS Actor in the Store?

There is one established GDACS Actor, and it is a serious piece of work. An honest comparison, feature by feature, taken from its own published input schema and dataset schema on 2026-09-11:

Where this Actor is ahead

• The cap. The reference Actor's maxResults tops out at 500, and its alert-level input is a single choice including ALL. This one splits the window until nothing is cut off, and never sends ALL - which, as measured above, returns an empty body.
• Alert levels and hazard types are multi-select, not one-at-a-time. You can ask for Red and Orange earthquakes and floods in a single run.
• Source fields it does not expose: episode_id, episode_alert_level, episode_alert_score, alert_score, glide, iso3, bbox, polygon_label, icon_url, and the whole event-card block - magnitude, depth_km, population_exposed, shake_population, episode_count and the map imagery - plus the affected-area polygons.
• Population exposure comes from GDACS, not from a bundled list of roughly 150 cities.
• Price: $0.99 per 1,000 events against $2.50 per 1,000.

Where the reference Actor is ahead, stated plainly

• It ships operational presets - profiles, modes, personas and view presets - and a large derived layer: posture, pressure index, playbooks, priority queues, recommended actions, review SLAs. This Actor has none of that. It returns what GDACS published and leaves the judgement to you.
• It has a replay mode that rebuilds a previous run from a stored snapshot, and diffing against a named reference run. This Actor's change tracking is the simpler NEW / UPDATED / UNCHANGED tagging described above.
• It has named region presets. Here you pass a bounding box or a country list.
• It bundles a city table, so it can name a nearest major city for hazards other than earthquakes. This Actor only measures against sites you supply.

If the derived decision layer is what you are buying, buy that one. If you want the complete event set with the source's own numbers, at a price that lets you run it hourly, this is the one.

What this Actor does not do

• It does not invent severity scores, priorities or recommended actions.
• It does not merge other feeds. GDACS only. USGS, NOAA and FEMA are separate sources with separate quirks and belong in separate Actors.
• It cannot recover a single day where one hazard type at one alert level still exceeds 100 events. It reports those days instead of hiding them.
• It does not translate. GDACS publishes in English.

FAQ

How far back does GDACS go? Events are available back to 2000. The wider the window, the more splitting the Actor has to do, and the more queries it spends - the run report tells you exactly how many.

Do I need an API key, a proxy or a browser? No. All three GDACS endpoints used here answer plain HTTP requests with JSON. That is checked on every live test run.

Why did my run return nothing? Most often because the default level selection is Red and Orange and your window was quiet. Widen the window, or add Green. The report's filtered_out block will also tell you if your own filters removed everything.

Can I run it on a schedule? That is what it is built for. Combine a short window with onlyNew and you pay only for events that appeared or changed since the previous run.

Why is severity sometimes tiny and sometimes in the hundreds of thousands? Because the unit differs per hazard: magnitude for earthquakes, km/h for cyclones, hectares for wildfires, square kilometres for droughts. Always read severity_unit before comparing, and use minSeverity with a single hazard type selected.

What is the difference between alert_level and episode_alert_level? The first is the colour for the whole event, the second for the latest episode only. They diverge when a situation is easing: the event stays Orange on its worst moment while the current episode has already dropped to Green.

Are empty fields a bug? No. magnitude is empty for a flood, glide is empty until a GLIDE number is assigned, event_name is empty for everything except named storms. Turn on excludeEmptyFields if you would rather not see the keys at all.

Can I get the output straight into a map? Use the Map view of the dataset, or turn on includeGeometry for real polygons rather than points.

Where does the data come from, and may I use it?

From gdacs.org, the Global Disaster Alert and Coordination System, a joint framework of the United Nations and the European Commission. The Actor reads three public endpoints: the event list, the event card and the polygon service. It does not log in, does not bypass anything and does not touch pages that require a browser. Check GDACS's own terms for how you may redistribute their data; this Actor delivers it to you unchanged apart from typing and field naming.