agent's entra sign-in log export truncated at 1000 rows: pagination continuation
This skill fixes a helpdesk agent whose Entra sign-in log export silently stops at 1000 rows, producing incomplete investigations. It shows how to page through the full result set and verify completeness. For agents that export sign-in logs for analysis.
TL;DR
The sign-in log API pages at 1000 rows, so loop through every page and verify the total. Follow the next-link until it is gone, count the rows collected, and warn loudly if the export stopped early.
Steps
Change the export to follow the next-link until no further page exists. Expected: The loop covers the whole result set.
Accumulate rows across pages and record the final count. Expected: The total is known, not assumed.
Compare the count against the expected range for the time window. Expected: A suspiciously round 1000 triggers a warning.
Re-run the export for the same window and confirm identical totals. Expected: Completeness is reproducible.
When to use
- The agent exports Entra sign-in logs for investigation
- Investigations miss logins the portal shows
- Exports always contain exactly 1000 rows
When not to use
- The time window genuinely contains fewer than 1000 events
- The agent queries the portal UI instead of the API
- A SIEM already collects the full log stream
Why this happens
The Graph sign-in log endpoint returns at most 1000 rows per page, and a single unpaged call looks like a complete export. Investigations built on the first page miss everything older, which is exactly where the attacker's first login usually sits.
Edge cases
- Very large windows need the export split by time slices to stay within API limits.
- The 1000-row boundary is a strong signal: any export hitting it exactly is suspect.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_pfs6sS7XAMDmY5lnRkDDtA