Clarification on uniqueness of alert id

[michael-digi]

Hey guys, I was wondering if you could answer a couple of questions about the JSON returned from the alerts endpoint. I understand that when a feature/alert is made, the id associated is globally unique. I also understand that a messageType can be alert update or canceled.

Is update or canceled a modification of an existing alert with an existing id, or does that just communicate that this is new entry about a previous alert with a different id?

What qualifies as an update? Will an affected zone get added to the "UGC" array and the messageType get changed to update? I'm assuming a change in the description, headline, severity etc will flip the bit to update.

Thanks!

[JJKraw]

Don't take this as a definitive answer, but what I've seen is that when the initial "alert" or a followup "update" is about to expire ("expires", as opposed to "ends"), a the "update" is issued with a new ID and the "references" section contains all of the previous alerts/IDs associated with the event.

[michael-digi]

@JJKraw Thanks for the response, I did some digging in the API yesterday and what you said seems to be the case. I guess the question now is, will those "updates" ever be the exact same data as the previous update or alert, as "expires" is probably just a cue to refresh?

[jah1007]

NWS offices issue products on a regular six hour cycle. The “expires” field represents when that product should stopped being used as an “active” alert. That said there are plenty of times where, due to workloads, the updates come in after the “expires” time which is why the eventEndingTime field is what ultimately determines when the alert has actually expired.