Sentinel incidents API: createdTimeUtc filter missed incidents that showed up later

I do not know of a documented upper bound for how late an incident can appear, so I would not rely on one. What I can say is why a createdTimeUtc filter is fragile for this: that timestamp is when the incident was created at its source (for Defender XDR incidents, when it was created there), and the record reaches Sentinel afterwards. So an incident can show up in the API after its createdTimeUtc has already passed, and a poll that only looks at a recent creation window can miss it, even with overlap. Your 20 minute windows did not help here because the delay was longer than the overlap.

Ways to make the poller robust, in the order I would try them:

• Filter on lastModifiedTimeUtc and keep a watermark. An incident that is synced in late also gets a modified time later, so a query for lastModifiedTimeUtc greater than your last watermark (minus a safety margin) catches new incidents and changes to old ones.
• Use the SecurityIncident table in Log Analytics instead, and filter on ingestion_time() greater than your watermark. Ingestion time is the right field for catching late arrivals, and you can dedupe on IncidentNumber and take the latest row per incident.
• Detect gaps. Incident numbers increase in your workspace, so if your poll sees numbers 100, 101 and 103, you know 102 is missing and you can re-query it later instead of assuming it never existed.
• If you want events, not polling, use an automation rule or playbook on incident creation to push to your system (Logic App, or Event Hub), and keep a slow reconciliation poll as the safety net.

For the four missed incidents, I would open a support case with their incident numbers, creation times and the time you first saw each one. The five minute figure in the docs is a typical value, and the exact timings of those four give the Sentinel team something concrete to check.