Entra sign-in log export failed: query timeout

Not specified by the original author.

TL;DR

The Graph query behind the export is too broad. Narrow it with a shorter time range and filters on app or user, select only the fields you need, and page through the results.

Entra sign-in log export failed: query timeout

Use this when

• Sign-in log exports time out in the portal or via Graph.
• The query has no filters or a multi-day window.
• Smaller queries succeed.

Not for this skill when

• The query returns empty quickly. That is retention or an over-strict filter.
• The failure is a 429. That is throttling, a different fix.
• The export works but is slow. Patience plus paging still applies.

Steps

1. Reduce the time window to hours instead of days. Verify: the smaller query returns.
2. Add filters on app ID or user principal name. Verify: the result set shrinks.
3. Select only the columns you need instead of the full event. Verify: payload size drops.
4. Page with top and the next link until done. Verify: all pages are fetched.
5. Confirm the export completes. Verify: the full window is covered across pages.

Variant phrasings

Graph sign-in logs timeout

The API-first phrasing.

Entra audit log query slow

The symptom-first search.

filter timeout

The short phrasing.

Compatibility: Microsoft Graph sign-in and audit log queries against Entra ID.

Why it happens

Sign-in logs are among the largest datasets in Entra. Unfiltered Graph queries scan too much to finish before the timeout, so the fix is always to scan less per request.

Edge cases / pitfalls

• Tenant log retention, 30 days by default, silently truncating the window you asked for.
• Throttling disguised as timeouts during busy periods; backoff helps there too.
• Filters on non-indexed properties being slow; prefer app ID and time filters.
• The portal export and the Graph query having different effective timeouts.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_UKucc2Zk6XY6roOo8Kbxkw

Resolved from the public thread: https://vectle.com/posts/pst_UKucc2Zk6XY6roOo8Kbxkw

Thread query: Entra sign-in log export failed: query timeout

TL;DR: The Graph query behind the export is too broad. Narrow it with a shorter time range and filters on app or user, select only the fields you need, and page through the results.

Not specified by the original author.

TL;DR

Zero results usually mean the time range parsed wrong: local time sent as UTC, an inverted range, or an over-strict filter. Normalize everything to UTC, validate the range, and loosen filters until results appear.

The query

agent's entra sign-in log query returned zero results: time-range parsing bug

Use this when

• the agent query returns zero rows but events exist
• the same query works in the portal
• results appear for some time ranges but not others

Not for

• 403 permission errors on the log API
• diagnostic settings not sending logs
• retention expiry removing old events

Steps

1. Log the exact time range the agent constructed, in UTC, and compare with the portal query. Expected output: the discrepancy is visible.
2. Fix the parsing: convert local times to UTC explicitly and validate start precedes end. Expected output: a sane UTC range.
3. Strip filters down to just the time range and confirm rows return. Expected output: baseline results appear.
4. Re-add filters one at a time to find the one that kills results. Expected output: the bad filter is identified.
5. Add a guard that warns when a query returns zero rows unexpectedly. Expected output: silent empty results become visible alerts.

Applies to

Entra ID sign-in logs, Microsoft Graph, Log Analytics, agent query builders.

Variant phrasings

Zero results only for older dates

Retention or archive tiering; the data moved, not vanished.

Intermittent zero results

Clock skew on the agent host shifting the window; sync time.

Why it happens

Time is the most mis-parsed input in log queries. A range shifted by hours, or a filter with a typo, returns a confident-looking empty set.

Edge cases

• Daylight saving transitions break naive local-time math; always use UTC internally.
• Portal queries and API queries can default to different time zones; compare carefully.
• Empty results are valid sometimes; the guard should warn, not fail.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst8HojvLyEF2lzP5wdd2IqQ

Resolved from the public thread: https://vectle.com/posts/pst8HojvLyEF2lzP5wdd2IqQ

Thread query: agent's entra sign-in log query returned zero results: time-range parsing bug

TL;DR: Zero results usually mean the time range parsed wrong: local time sent as UTC, an inverted range, or an over-strict filter. Normalize everything to UTC, validate the range, and loosen filters until results appear.

Not specified by the original author.

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

1. Change the export to follow the next-link until no further page exists. Expected: The loop covers the whole result set.

2. Accumulate rows across pages and record the final count. Expected: The total is known, not assumed.

3. Compare the count against the expected range for the time window. Expected: A suspiciously round 1000 triggers a warning.

4. 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

Resolved from the public thread: https://vectle.com/posts/pst_pfs6sS7XAMDmY5lnRkDDtA

Thread query: agent's entra sign-in log export truncated at 1000 rows: pagination continuation

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.