Global CAP Review — 2026-10-10

About This Report

This daily summary of global public warning activity is compiled from public emergency alerts issued in the Common Alerting Protocol (CAP) format by official alerting authorities around the world. It covers a single 24-hour period (UTC) and includes only those messages AlertHub.org obtained and republished; coverage completeness and accuracy are not guaranteed. This report should never be used as a substitute for official distributions of alerts.

This report is a personal project and is not sponsored or endorsed by any national, international or corporate entity.

In addition to a daily recounting of global CAP activity, this report also provides a qualitative review of CAP alerts, both for standards-compliance and from an opinionated but evidence-based warning-effectiveness perspective. The effectiveness principles are drawn from scientific research into what makes warning messages yield desired results, filtered through my experience both as the proponent and designer of CAP, and as a public-safety warning originator. These principles (see below) are offered to encourage global adoption of warning best practices, aimed at maximizing global warning system interoperability as well as protective action by people at risk.

The author represents no nation, institution, or interest in providing this report. The review here is offered as a personal initiative aimed at encouraging global adoption of evidence- and experience-based best practices in warning message composition..

Art Botterell

Please address comments and suggestions to art@botterell.net.

---

Message Content - Test Rules

The Global CAP Report applies the following recommendations for maximum warning message effectiveness:

1. usc_all_unknown — <urgency>, <severity> and <certainty> all reported as Unknown. This usage makes categorization difficult for automated systems and for displays that style alerts depending on one or more of these settings.
2. no_headline — <headline> element is empty. CAP schema makes it optional but its use is recommended, as many downstream renders use it as a primary label for the message.
3. local_abbreviations — <description>, <instruction>, or <areaDesc> element contains an unwhitelisted uppercase 2–6-letter token (e.g. JCOES). Such abbreviations may be unfamiliar to travelers or newcomers to the local area. Whitelist includes WMO / UN bodies, US federal agencies, US state codes, cardinal directions, common time units, etc, The offending token is specified in the badge. .
4. no_description_explains_effects — <description> text names the hazard but does not describe the effects on people, property, or infrastructure. Fires if description is empty, identical to headline, or shorter than 60 characters. Anything that passes that gate goes to LLM for semantic check.
5. no_instruction_text — <instruction> is empty. The message describes a hazard but tells the reader nothing to do about it.
6. no_instruction_time — <instruction> does not say by when the protective action should be taken. Fires if the text contains no time reference (clock time, within N minutes, by 3 PM, immediately, etc.). Anything that passes goes to LLM for semantic check. Silent when there is no instruction at all, which the rule above covers.
7. no_specific_area_geometry — At least one <area> block has neither a <polygon> nor a <circle> value. Specific geometries are recommended to allow recise message delivery and reduce alert deliveries to people not actually at risk ("spill")
8. senderName_not_registered — <senderName> should contain the sender's registered agency name (WMO, IPAWS or other national registry). Currently fires when the value is empty, an email address, a URL, or an obvious placeholder ("unknown", "n/a", "test"). A future revision will also fire when the value does not match a known registry entry.
9. no_expires — An <info> block carries no <expires>. CAP makes the element optional but a receiver given no expiry has no way to know when to stop displaying or forwarding the alert. Systems are left to guess and may either drop the message too early or leave a stale warning on screen after the hazard has passed.
10. encoding_not_declared — The message does not assert what character encoding it uses. The receiver may guess wrong and that can render local language unreadable.
11. test_as_actual — The message announces itself in its headline or event as a test, but its <status> claims it is Actual. This can result in inappropriate routing or delivery of the message.
12. usc_divergent_between_infos — All <info> elements within a single <alert> should have the same urgency, severity, and certainty values to allow the alert to be processed consistently as a unit. Messages with different U/S/C values should be sent in separate <alert> bodies.
13. no_cancel_in_alert_or_update — Cancellations should travel in separate <alert> bodies to avoid confusion. No form of the word "cancel" should appear in the <headline>, <description> or <instruction> elements of any <info> within any <alert> of any type other than "Cancel"
14. non_latin_script — An <info> block declares English, or declares no <language> at all (which CAP reads as en-US), but its text is written in another script — Cyrillic, Han, kana, Hangul, Arabic, Greek, Hebrew, Devanagari or Thai. A receiver that selects blocks by language, or picks a font or a speech voice from it, is handed text it cannot render or read aloud. Accented Latin is not flagged: Päijät-Häme and BÉJAÏA are English-language usage.
15. multiple_categories — An <info> block declares more than one <category>. CAP permits it, but a receiver that routes, styles or files an alert by category has to choose one, and different receivers choose differently, so the same message reaches different audiences on different systems.
16. category_divergent_between_infos — All <info> elements within a single <alert> should declare the same <category> values, so the alert can be routed consistently as a unit.