Inconsistent number of rows from calling Graph API with the same time range

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

https://graph.microsoft.com/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)

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.com/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.