What is the average reporting time for Alerts? (time taken between an incident occurring and a notification being issued)
This depends on several things, such as how soon our systems pick up the incident or the nature of the incidents happening that day, which determines their priority. However, for ‘breaking’ incidents, which present an immediate threat to traveller safety, we aim to send our first Alert within ten minutes of our notification of the incident. For all other incidents or events, we aim to publish an Alert within 20 minutes of being notified if it is high priority.
How is the impact radius established?
The “impact radius” is an estimate our analyst makes when writing an Alert.
The radius is an area of probable impact. However, not all areas within the radius will be impacted in reality.
For instance, if the analysts have a great degree of uncertainty about exactly where the report incident took place, this may increase the impact radius.
Examples:
- If we know a shooting took place at X School, then we can use a smaller radius (maybe 500m only)
- If we only know that a shooting took place somewhere near X Town, we will use a larger radius to include most or all of X Town and some surrounding area
Why do some Alerts have no radius?
If an Alert has no impact radius, it is because the impact is city, region or country-wide, and we will indicate in the title which city, region or country is impacted. You can find more details about the latest version of our Alerts here
Are Subcategories present in all Alerts?
Subcategories are not mandatory fields, therefore, they are not present in al Alerts
Which field/s of the Json payload should be used to target the right people with each Alert?
The impacted_areas field. You can find more information hon ow to precisely target the right traveller with an Alert here
When would you send a PUT request?
We would send a PUT request, for corrections to Alerts (fact correction, typo correction). Corrections can be made to: text, Risk Level, Category or sub-category, airport codes, or we can do a minor latitude/longitude adjustment. We will not change dates or the impacted country or city, such things are seen as major corrections and would warrant a DELETE and new POST.
What is the procedure followed when an Alert is published with incorrect dates or country/city?
- A new Alert is created with the correct information and published (POST request). This Alert is not connected to the Parent/incorrect Alert (so an Alert ID will not show in the relations sections).
- Another new Alert is created with a relation to the incorrect Alert (therefore, an Alert ID will show in the relations section) to indicate a change in the original Alert. The word "-Correction" will be added to this Alert title. The Alert will have the same incorrect dates or country/city as the original. This Risk Level will be set as "Low". This Alert will then be published (POST request).
- The analyst will then - in this order - delete the "-Correction" Alert and then delete the original incorrect Alert (DELETE request).
What is the procedure followed when there is a “cancelled upcoming event” Alert? Eg. when an Alert has been sent weeks/months in advance for an upcoming event (eg. a protest or strike) and it was later postponed or cancelled.
In those cases the procedure is to:
- Create a new Alert with a new id (linked to the parent id of the original one)
- Make the original Alert inactive - so you would receive a PUT request