I have an app that is calling Graph API endpoints using a URL that looks like this:

.0/auditLogs/signIns?$filter=(createdDateTime ge 2025-03-17T17:32:34.650740Z and createdDateTime lt 2025-03-17T17:37:34.650740Z)&$orderby=createdDateTime desc

I would expect the result (e.g. total rows) from this URL call to return the same set of result all the time since the time boundaries are set, but I seem to be getting different total rows returned, mostly increasing. Is this an expected behavior, if not what could be the reason, and is there a general way to solve/manage it?

The timestamp in the example were called in real time (45 rows), then a few seconds (271 rows) later then 5 minutes later (742 rows), 10 minutes later (742 rows)

I have an app that is calling Graph API endpoints using a URL that looks like this:

https://graph.microsoft/v1.0/auditLogs/signIns?$filter=(createdDateTime ge 2025-03-17T17:32:34.650740Z and createdDateTime lt 2025-03-17T17:37:34.650740Z)&$orderby=createdDateTime desc

I would expect the result (e.g. total rows) from this URL call to return the same set of result all the time since the time boundaries are set, but I seem to be getting different total rows returned, mostly increasing. Is this an expected behavior, if not what could be the reason, and is there a general way to solve/manage it?

The timestamp in the example were called in real time (45 rows), then a few seconds (271 rows) later then 5 minutes later (742 rows), 10 minutes later (742 rows)

• azure
• microsoft-graph-api

• 1 Ensure you use a consistent timestamp window (e.g., a static window to avoid the influence of new data). – Rukmini Commented Mar 18 at 9:28
• 1 The increasing row counts are likely due to real-time data updates or eventual consistency in the system. To manage this, try using a slightly broader time range for your queries, ensuring consistent time zone and precision usage, or periodically re-running your queries to capture all logs. – Rukmini Commented Mar 18 at 9:56
• Any update on the issue? – Rukmini Commented Mar 20 at 3:36
• 1 @Rukmini Thanks for the follow up, you're correct; I was polling the data too early. When I delayed fetching the data, I got all the data. If you don't mind, please give a proper answer so I can accept it. – hello Commented Mar 20 at 14:55
• 1 Sure will post an answer:) – Rukmini Commented Mar 20 at 15:18

1 Answer 1

The increasing row counts are likely due to real-time data updates or eventual consistency in the system. To manage this, try using a slightly broader time range for your queries, ensuring consistent time zone and precision usage, or periodically re-running your queries to capture all logs.

• Ensure you use a consistent timestamp window (e.g., a static window to avoid the influence of new data).

In your scenario the issue is due to polling the data too early which lead to inconsistencies due to the time it takes for all events to be processed and indexed in the backend.

• The Microsoft Graph API operates with eventual consistency, the data may not be fully available immediately after the event occurs, especially in large-scale systems.

GET https://graph.microsoft/v1.0/auditLogs/signIns?$filter=(createdDateTime ge 2025-03-17T17:32:34.650740Z and createdDateTime lt 2025-03-21T17:37:34.650740Z)&$orderby=createdDateTime desc

Hence Delaying the data fetch will allow all the data to be indexed.