Google CAP requirements
Stay organized with collections
Save and categorize content based on your preferences.
Your alerting data should follow the OASIS Common Alerting Protocol
v1.2
specification, plus the Google Public Alerts CAP v1.0
specification and additional requirements noted below.
About Google CAP
The CAP standard establishes the basic structure and data elements for a CAP
alert, but still leaves considerable room for inconsistencies in how and when
the various data elements are employed.
Our platform aims to simplify the process of finding emergency information by
bringing together high-quality, relevant data inside online tools that people
already use every day. The additional requirements are meant
to maximize the reach and effectiveness of your alerts on Google
products.
Google-specific differences with the CAP 1.2 XML requirements are summarized
in the Google Public Alerts CAP v1.0 specification.
The "Google Public Alerts CAP" option in the open-source CAP
Validator allows you to validate your data
against both the OASIS spec and Google's additional requirements.
The guidelines below apply to all types of alerts and hazards. We've also put
together a few additional requirements and recommendations for these specific
alert types in our Samples section:
- Ensure your system is capable of publishing alerts with
<status>Test</status> in order to perform regular end-to-end
system tests.
Target alerting areas
- If there are non-contiguous areas under the same alert level and type, create
separate
<alert> messages rather than a single <alert> with
disjointed areas.
- If the
<area> element contains <polygon> elements, ensure they're valid
polygons without self-intersecting edges or overlapping polygons, and specify
a maximum of 6 decimal points of precision.
- If the
<area> element of your alerts contains geocodes, provide the
geodata in shapefile format
and notify Google at google-public-alerts@google.com at
least 30 days before any shapefile changes.
- Draw impact-based polygons that are customized for current conditions and the
nature of the event wherever possible, rather than targeting alerts to
predefined geopolitical areas (e.g. provinces, districts).
- Provide Google with a short (less than 50 characters) description of the
affected area in the
<areaDesc> or in a separate dedicated <parameter>
of your CAP alerts. This text will be displayed in the alert title.
Include rich content
- Include rich, actionable, human-readable content in the
<description>
and <instruction> elements.
- Describe the current event, predicted developments, expected impact, and
recommendations as applicable.
- Use correct spelling, grammar, and punctuation.
- Use plain-text to improve the readability of your content, rather than HTML
tags.
- Provide RGB or hex color codes corresponding to each alert level (can be
provided to Google offline).
Updating alerts
When an alert changes, issue a new alert
that refers to the previous alert, instead of changing or removing the existing
alert from your feed. After an appropriate amount of time (up to two weeks),
remove stale CAP alerts from your feed.
<msgType> UPDATE or CANCEL must include at least one <references> element.
As specified in the CAP standard, any alert message that updates a previous
alert should use <msgType>Update</msgType> and set <references>code</references>
to all previous related messages that haven't reached their <expires> date.
The UPDATE or CANCEL must apply to a non-expired alert.
There are three ways to CANCEL events, in order of preference:
- Set an
<expires> datetime for each event, with the message
description setting the expectation that this alert will end on its
own.
- Issue a new
<alert> with <msgType>UPDATE,
<responseType>"All Clear", and <expires> a short time in
the future.
- Issue a new
<alert> with <msgType>CANCEL.
Please see our Sample Alerts for updates and cancellations for examples.
Supporting multiple languages
Please create one <alert> containing multiple <info> blocks
(one <info> block per language).
For more details and a sample multi-lingual alert, see Multiple languages.
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2025-08-28 UTC.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Missing the information I need","missingTheInformationINeed","thumb-down"],["Too complicated / too many steps","tooComplicatedTooManySteps","thumb-down"],["Out of date","outOfDate","thumb-down"],["Samples / code issue","samplesCodeIssue","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-28 UTC."],[[["\u003cp\u003eAlerting data must adhere to the OASIS Common Alerting Protocol v1.2, the Google Public Alerts CAP v1.0, and additional Google-specific requirements.\u003c/p\u003e\n"],["\u003cp\u003eGoogle's platform aims to centralize and standardize emergency information by incorporating high-quality, relevant alert data into its widely used products.\u003c/p\u003e\n"],["\u003cp\u003eAlerts should include detailed, actionable information in plain text, focusing on current events, predictions, impacts, and recommendations, while adhering to grammar and spelling conventions.\u003c/p\u003e\n"],["\u003cp\u003eWhen updating an alert, issue a new alert referencing the previous one instead of modifying it directly; use the \u003ccode\u003e<msgType>\u003c/code\u003e "Update" or "Cancel" appropriately and remove stale alerts from the feed after a reasonable timeframe.\u003c/p\u003e\n"],["\u003cp\u003eFor multilingual alerts, create a single \u003ccode\u003e<alert>\u003c/code\u003e element containing multiple \u003ccode\u003e<info>\u003c/code\u003e blocks, each dedicated to a different language.\u003c/p\u003e\n"]]],["Alert data should follow OASIS CAP v1.2 and Google's specifications. Key actions include: validating data with the CAP Validator, performing system tests with `\u003cstatus\u003eTest\u003c/status\u003e`, creating separate `\u003calert\u003e` messages for non-contiguous areas, using valid polygons, and providing shapefiles for geocodes. Alerts should have rich content in `\u003cdescription\u003e` and `\u003cinstruction\u003e`, be updated by issuing new alerts referencing previous ones, and support multiple languages via multiple `\u003cinfo\u003e` blocks. Cancel alerts with `\u003cexpires\u003e`, `\u003cresponseType\u003e\"All Clear\"` or `\u003cmsgType\u003eCANCEL`.\n"],null,["# Google CAP requirements\n\nYour alerting data should follow the OASIS [Common Alerting Protocol\nv1.2](http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.html)\nspecification, plus the [Google Public Alerts CAP v1.0](/public-alerts/reference/cap-google)\nspecification and additional requirements noted below.\n\nAbout Google CAP\n----------------\n\nThe CAP standard establishes the basic structure and data elements for a CAP\nalert, but still leaves considerable room for inconsistencies in how and when\nthe various data elements are employed.\n\nOur platform aims to simplify the process of finding emergency information by\nbringing together high-quality, relevant data inside online tools that people\nalready use every day. The additional requirements are meant\nto maximize the reach and effectiveness of your alerts on Google\nproducts.\n\nGoogle-specific differences with the CAP 1.2 XML requirements are summarized\nin the [Google Public Alerts CAP v1.0](/public-alerts/reference/cap-google) specification.\n\nThe \"Google Public Alerts CAP\" option in the open-source [CAP\nValidator](http://cap-validator.appspot.com) allows you to validate your data\nagainst both the OASIS spec and Google's additional requirements.\n\nThe guidelines below apply to all types of alerts and hazards. We've also put\ntogether a few additional requirements and recommendations for these specific\nalert types in our [Samples](/public-alerts/samples/sample-alerts) section:\n\n- [Tropical storms](/public-alerts/samples/storm-alerts#special_recommendations_on_cap_for_tropical_storms)\n- [Earthquakes](/public-alerts/samples/earthquake-alerts#special_recommendations_on_cap_for_earthquakes)\n- [Tsunamis](/public-alerts/samples/tsunami-alerts#special_recommendations_on_cap_for_tsunamis)\n\nPerform periodic testing\n------------------------\n\n- Ensure your system is capable of publishing alerts with `\u003cstatus\u003e`Test`\u003c/status\u003e` in order to perform regular end-to-end system tests.\n\nTarget alerting areas\n---------------------\n\n- If there are non-contiguous areas under the same alert level and type, create separate `\u003calert\u003e` messages rather than a single `\u003calert\u003e` with disjointed areas.\n- If the `\u003carea\u003e` element contains `\u003cpolygon\u003e` elements, ensure they're valid polygons without self-intersecting edges or overlapping polygons, and specify a maximum of 6 decimal points of precision.\n- If the `\u003carea\u003e` element of your alerts contains geocodes, provide the geodata in [shapefile](https://en.wikipedia.org/wiki/Shapefile) format and notify Google at [google-public-alerts@google.com](mailto:google-public-alerts@google.com) at least 30 days before any shapefile changes.\n- Draw impact-based polygons that are customized for current conditions and the nature of the event wherever possible, rather than targeting alerts to predefined geopolitical areas (e.g. provinces, districts).\n- Provide Google with a short (less than 50 characters) description of the affected area in the `\u003careaDesc\u003e` or in a separate dedicated `\u003cparameter\u003e` of your CAP alerts. This text will be displayed in the alert title.\n\nInclude rich content\n--------------------\n\n- Include rich, actionable, human-readable content in the `\u003cdescription\u003e` and `\u003cinstruction\u003e` elements.\n- Describe the current event, predicted developments, expected impact, and recommendations as applicable.\n- Use correct spelling, grammar, and punctuation.\n- Use plain-text to improve the readability of your content, rather than HTML tags.\n- Provide RGB or hex color codes corresponding to each alert level (can be provided to Google offline).\n\nUpdating alerts\n---------------\n\nWhen an alert changes, [issue a new alert](http://docs.oasis-open.org/emergency-adopt/cap-feeds/v1.0/cn02/cap-feeds-v1.0-cn02.html#_Toc382489987)\nthat refers to the previous alert, instead of changing or removing the existing\nalert from your feed. After an appropriate amount of time (up to two weeks),\nremove stale CAP alerts from your feed.\n\n`\u003cmsgType\u003e` UPDATE or CANCEL must include at least one `\u003creferences\u003e` element.\nAs specified in the CAP standard, any alert message that updates a previous\nalert should use `\u003cmsgType\u003eUpdate\u003c/msgType\u003e` and set `\u003creferences\u003ecode\u003c/references\u003e`\nto all previous related messages that haven't reached their `\u003cexpires\u003e` date.\nThe UPDATE or CANCEL must apply to a non-expired alert.\n\nThere are three ways to CANCEL events, in order of preference:\n\n1. Set an `\u003cexpires\u003e` datetime for each event, with the message description setting the expectation that this alert will end on its own.\n2. Issue a new `\u003calert\u003e` with `\u003cmsgType\u003eUPDATE`, `\u003cresponseType\u003e\"All Clear\"`, and `\u003cexpires\u003e` a short time in the future.\n3. Issue a new `\u003calert\u003e` with `\u003cmsgType\u003eCANCEL`.\n\nPlease see our [Sample Alerts for updates and cancellations](/public-alerts/samples/alert-updates) for examples.\n\nSupporting multiple languages\n-----------------------------\n\nPlease create one `\u003calert\u003e` containing multiple `\u003cinfo\u003e` blocks\n(one `\u003cinfo\u003e` block per language).\n\nFor more details and a sample multi-lingual alert, see [Multiple languages](/public-alerts/samples/multiple-languages)."]]
