Share via

Delayed Event Availability / Ingestion Latency on Entra ID riskDetections Graph API Endpoint

Nisha Das 30 Reputation points
2026-06-18T07:06:39.4233333+00:00

Hi,

We are currently ingesting Entra ID Risk Detection events into our platform using the Microsoft Graph API v1.0 endpoint: GET /identityProtection/riskDetections

We have implemented a time-based polling mechanism, but we are noticing that several risk events are missing during our real-time queries, only to show up much later.

The Problem / Scenario

When a risk event is triggered, it appears in the API with a historical timestamp (matching the actual event time), but there is a noticeable propagation delay before it becomes visible to a GET request.

For example, if an event's detectedDateTime is 1:05 PM, and we run our ingestion query at 1:10 PM, that event is missing from the response payload. However, if we replay the exact same query an hour later, the event is successfully returned.

Here is the query structure we are running :

graph.microsoft.com/v1.0/identityProtection/riskDetections?$top=500&$filter=detectedDateTime ge 2026-06-16T01:00:59.969Z and detectedDateTime le 2026-06-16T01:10:59.969Z&$orderby=detectedDateTime asc

Questions:

Is there an expected or documented data latency/propagation delay for the /identityProtection/riskDetections endpoint before events become queryable via Graph API?

  1. If there is a delay, what is the maximum or average SLA/window we should expect?
Microsoft Security | Microsoft Entra | Microsoft Entra ID

Answer accepted by question author

Shubham Sharma 17,675 Reputation points Microsoft External Staff Moderator
2026-06-18T07:36:53.8966667+00:00

Hey Nisha, it isn’t just you – the identityProtection/riskDetections endpoint is eventually consistent, and there is a built-in propagation window before new events become queryable.

Here’s the key guidance:

  • Real-time detections (the ones calculated “during” sign-in) typically take about 5–10 minutes to surface in the API.
  • Offline detections (those that need additional signals or batch processing) can take up to 48 hours before they show up.

Because of that, time-based polling needs a little “grace period” to catch late-arriving events. In practice people often:

  1. Poll with a slight overlap (for example, re-query the last 5–10 minutes in each run) so you don’t miss events that arrived late.
  2. Use $orderby=detectedDateTime asc together with $skiptoken (or save the last detectedDateTime you saw minus your overlap) to page through consistently.

There isn’t a formal SLA published for how quickly risk detections become queryable, but in our experience:

  • Expect new real-time risk detections to show up within about 5–10 minutes.
  • Allow up to a couple of hours for most events, and up to 48 hours for some offline calculations.

Hope that helps you tune your polling window!

References:

https://learn.microsoft.com/entra/id-protection/concept-risk-detection-types#real-time-and-offline-detections

If the answer is helpful, kindly upvote it. If you have extra questions about this answer, please click "Comment".

Was this answer helpful?

1 person found this answer helpful.
0 comments

0 additional answers

Sort by: Most helpful
Most helpful Newest Oldest

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.