AusAlert
How the Common Alerting Protocol underpins cell broadcast, and which parts are documented rather than reported.
CAP-AU is the Common Alerting Protocol, Australian Profile. It is an XML standard for formatting emergency alert messages, based on the international OASIS CAP v1.2 specification. OASIS reports that 87% of the world's population lives in a country with at least one national CAP alert feed.
The Bureau of Meteorology (BOM) is the custodian of CAP-AU. The current version is CAP-AU-STD v3.0, published in September 2013. It was developed by a working group including Emergency Management Australia, Geoscience Australia, and state government agencies.
CAP-AU adds Australian-specific extensions to the base standard: event code mappings aligned with the AUeventLIST, and geocoding conventions using G-NAF, Gazetteer, postcode and ISO 3166-2 references on the GDA94 datum.
Industry reporting indicates AusAlert uses CAP internally to standardise alert messages before they are sent via cell broadcast; official documentation does not describe the internal message format. The reported flow works like this:
The CAP message itself is not delivered to phones. Phones receive a condensed cell broadcast message derived from the CAP content. The full CAP record stays within the government system.
Emergency Agency (CFS, RFS, etc.)
|
v
CAP-AU Message (XML)
|
v
Cell Broadcast Centre (CBC)
|
v
4G/5G Mobility Management (separate signalling channel)
|
v
Mobile Towers (targeted by WGS84 coordinates)
|
v
All Compatible Devices in Range
|
v
Display alert, play siren
(re-broadcast during the alert period,
so devices entering the area later still receive it)Cell broadcast uses a one-to-many architecture. One message from the tower reaches every device. No phone numbers, no subscriber data, no network congestion.
A CAP-AU alert has three main layers:
| Element | Key Fields | Purpose |
|---|---|---|
| <alert> | identifier, sender, sent, status, msgType, scope | Message envelope: who sent it, when, and whether it is Actual/Test/Cancel |
| <info> | category, event, severity, urgency, certainty, headline, description | Alert content: what happened, how serious, what to do |
| <area> | areaDesc, polygon, circle, geocode | Geographic targeting: where the threat is, polygon or circle boundaries |
For a deeper look at the CAP-AU format with code examples, see our CAP-AU Developer Guide.
Communications Alliance published standard AS/CA S042:2025 for cell broadcast device compatibility. From 30 June 2026, all relevant devices imported into Australia must comply.
Two alert levels with different device behaviour:
| Alert Type | User Can Disable? | Override Silent/DND? | Use Case |
|---|---|---|---|
| Critical | No | Yes (siren, vibrate, full screen) | Imminent threat to life |
| Priority | Yes (via phone settings) | No | Watch-and-act, advice |
Official compatibility: iPhone 11 and later on iOS 26.4 or later, Apple Watch SE2, SE3 and Series 6 and later on watchOS 26.4 or later, and Android devices on Android 12 or later. No SIM card is required. iPads are not supported.
EmergencyAPI publishes CAP-AU the way CAP was designed to be distributed: a standards-validated Atom feed at ?format=cap-atom, where each entry inlines a full CAP-AU <alert>, plus per-incident documents at /incidents/[id]?format=cap-au. Both validate against the OASIS CAP 1.2 schema and the CAP-AU Profile v3.0, confirmed with the Google CAP Validator.
The older ?format=cap-au list output wrapped multiple alerts in a non-standard element and did not validate as a whole. It is kept for backward compatibility but deprecated; new integrations should use the Atom feed.
While AusAlert reportedly uses CAP internally and does not expose it to developers, EmergencyAPI makes CAP-AU accessible. You can consume incident data in CAP-AU format for integration with emergency management systems, or use GeoJSON/CSV for mapping and analysis.
For implementation details, see the CAP-AU Developer Guide.
Build with CAP-AU formatted emergency data.