Delay between successful incident submission and availability via GET / UI

[ckeosayian-ff]

Hi all — we’re seeing something that may just be expected behavior during busy periods, but wanted to sanity-check with the team.

After submitting an incident via POST /incident, we receive a successful response and an incident number, but sometimes the incident isn’t immediately available via GET /incident and not yet visible in the NERIS UI.

In a few cases (especially during high-volume periods), it can take anywhere from several minutes to over several hours before the incident becomes queryable.

Totally understand this may be due to background processing or server load — we’re mainly looking to confirm whether this is expected behavior and, if so, whether there’s a recommended pattern for handling it on the client side (e.g. waiting a certain amount of time before attempting updates).

Appreciate any guidance or confirmation if other vendors have seen this as well.

[cweinschenk]

When an incident is submitted to NERIS, the data is queued for additional processing for validation and data augmentation for weather, census data, and other elements. While incident data processing is pending the incident data is in the submitted status and isn't available for a put/patch call. When load exceeds provisioned capacity, more resources are designed to automatically scale to meet demand. In the event that resources and demand are imbalanced, incident data will queue until such time they can be processed.

The other day, due to some spikes in submission activity (everyone awaking from the new year at once and submitted days of calls at time), combined with a failed scaling call, NERIS had to leverage the queue to a larger degree than we wanted. The team manually deployed additional resources which brought the processing queue back in alignment. This type of lag (on the hour magnitude) is not our plan.

We are still learning submissions trends from all the departments/vendors so we optimize resources and scaling rules. As such I cannot guarantee there won't be some spot times where the queue is long again in the short term. To help with this, we are working on publishing some queue status/metrics that can be used for self-service checks.

[ckeosayian-ff]

This is super helpful, thank you! A future queue status/metrics would be great to have in the future.