Entra sign-in logs vs SigninLogs

Background

Microsoft Entra sign-in logs are the authentication records Entra ID keeps for the tenant. They are what you see in the Entra admin center under Monitoring, on the Sign-in logs page. One row per sign-in attempt, including successes, failures, and interrupted flows such as expired password or Keep me signed in.

Microsoft Graph provides an API for this Entra sign-in data through GET /auditLogs/signIns. Both the portal and Graph expose the sign-in request ID and createdDateTime.

Azure Monitor SigninLogs is a separate representation of Entra sign-in activity stored in a Log Analytics workspace. It is populated through an Entra diagnostic setting, which exports selected Entra log categories to the configured destination. In this lab, the SignInLogs category (interactive user sign-ins) was exported to a Log Analytics workspace, where the corresponding table is named SigninLogs.

The Entra sign-in catalog and the Log Analytics table therefore should not be treated as the same evidence set. This study uses the request ID to compare individual sign-in attempts across the two stores.

The timestamps used in the analysis are:

• CreatedDateTime is the UTC timestamp recorded by Entra for the sign-in attempt. It is present for successful, failed, and interrupted attempts.
• TimeGenerated on a SigninLogs row represents the time the record was ingested into the Log Analytics workspace. It is not the time of the sign-in attempt.

Microsoft also documents that after a new diagnostic setting is configured, logs can take up to three days to start appearing in the destination. This activation delay is distinct from the ingestion latency of records that are already being received by the workspace.

The lab generated a controlled set of Entra sign-ins around the diagnostic-setting configuration and tracked their request IDs to determine which records appeared in SigninLogs and when.

Summary of findings

This lab compared a controlled set of Entra interactive sign-in request IDs with workspace table SigninLogs. The same seven IDs were queried between 2026-08-08 and 2026-08-18. The lab produced three major observations.

1. Events present in Entra sign-in logs may never appear in workspace SigninLogs

In this lab, seven sign-in request IDs were tracked across Entra and Log Analytics. IDs 1-3 occurred before the diagnostic setting was successfully written and were therefore outside the export period. IDs 4-7 occurred 10-11 minutes after the successful write, remained present in Entra, but never appeared in SigninLogs, even after later SigninLogs records began arriving and an exact-ID query was repeated on 2026-08-18.

2. Ingestion latency on records that arrive may exceed 15 minutes

For SigninLogs records that did arrive, TimeGenerated minus CreatedDateTime ranged from approximately 39 seconds to 16 minutes in the observed data. Later sign-ins from the same test user were ingested within approximately one to two minutes. The seven control IDs therefore cannot be explained by the ingestion latency observed on later records.

3. Sign-ins for the test user that happened after 2026-08-08 did appear in SigninLogs

OfficeHome sign-ins from timestamp-test-01 on 2026-08-09, 2026-08-11, and 2026-08-13 appeared in SigninLogs, including Entra-to-Log Analytics delays of 108.9, 75.6, and 106.8 seconds. The difference between these events and IDs 4-7 is therefore not explained by the user being excluded from the configured SignInLogs export.

Limitations

• In this lab the tenant did not have the required Entra ID Premium licensing, so Microsoft Graph sign-in audit API at GET /auditLogs/signIns was not used.
• One tenant, one workspace, interactive SignInLogs only. The diagnostic setting did not enable NonInteractiveUserSignInLogs, ServicePrincipalSignInLogs, or ManagedIdentitySignInLogs, so those catalogs are out of scope.
• The only destination was Log Analytics. This post cannot show whether some other export path would have received the same request IDs.

Lab setup

For this lab I used one Microsoft Entra tenant and one Azure subscription. A Log Analytics workspace is the Azure Monitor container that stores queryable tables. I created workspace law-entra-timestamp-lab in East US, pricing tier Pay-as-you-go (Per GB).

An Entra diagnostic setting is configured in Entra admin center -> Monitoring & health -> Diagnostic settings. I created setting entra-timestamp-research with:

• Log category SignInLogs enabled (interactive user sign-ins only).
• Destination: Log Analytics workspace law-entra-timestamp-lab.
• No other destinations.

Microsoft uses two spellings. SignInLogs is the diagnostic-setting category. SigninLogs is the table name in the Log Analytics workspace. They refer to the same export.

I used two identities:

• An administrator account ilyakobzar, which generated Azure Portal and Microsoft Azure Signup Portal sign-ins while the lab was being built.
• A dedicated test user, timestamp-test-01, which generated interactive sign-ins against the Microsoft 365 home-page application(hereinafter, OfficeHome).

Workspace create, the diagnostic-setting save, and the seven control sign-ins occurred on 2026-08-08. Screenshot filenames in the lab notes are local Eastern time (UTC -04:00 in August). UTC values below come from Entra exports, Log Analytics, and Azure Activity Log.

Experiments

I wrote the diagnostic setting, generated seven Entra request IDs around that write, and searched SigninLogs for those IDs. The timeline below shows the chronological sequence of the experiment, and the following subsections provide the detailed analysis and observations.

Timeline of key events (UTC)

* This record was an unrelated sign-in and did not match any of the seven controlled event IDs. Its TimeGenerated was 2026-08-09T04:59:45.960Z, meaning the record appeared in Log Analytics approximately 99.6 seconds after the sign-in was created. This was approximately 12 hours and 10 minutes after diagnostic-setting reporting was successfully configured at 2026-08-08T16:47:51.584Z.

** Interactive OfficeHome successes for timestamp-test-01 on 2026-08-09, 2026-08-11, and 2026-08-13, from the Microsoft 365 home page left open in the background. They appeared in SigninLogs about 1-2 minutes after CreatedDateTime.

When export was enabled

Creating the workspace does not start the export. In this lab, the relevant configuration event was the successful write of entra-timestamp-research. Tenant Activity Log recorded that write as microsoft.aadiam/diagnosticSettings/write at 2026-08-08T16:47:51.584Z, status Succeeded, HTTP 200. The request body enabled SignInLogs only and pointed at law-entra-timestamp-lab.

[
  {
    "eventName": { "value": "BeginRequest" },
    "eventTimestamp": "2026-08-08T16:47:50.4432913Z",
    "operationName": { "value": "microsoft.aadiam/diagnosticSettings/write" },
    "resourceId": "/providers/microsoft.aadiam/diagnosticSettings/entra-timestamp-research",
    "status": { "value": "Started" },
    "subscriptionId": "",
    "httpRequest": {
      "method": "PUT",
      "uri": "https://management.azure.com/providers/microsoft.aadiam/diagnosticSettings/entra-timestamp-research?api-version=2017-04-01-preview"
    },
    "properties": {
      "requestbody": "{\"name\":\"entra-timestamp-research\",\"properties\":{\"logs\":[{\"category\":\"SignInLogs\",\"enabled\":true}, ...],\"workspaceId\":\"/subscriptions/.../workspaces/law-entra-timestamp-lab\"}}"
    }
  },
  {
    "eventName": { "value": "EndRequest" },
    "eventTimestamp": "2026-08-08T16:47:51.5839118Z",
    "operationName": { "value": "microsoft.aadiam/diagnosticSettings/write" },
    "resourceId": "/providers/microsoft.aadiam/diagnosticSettings/entra-timestamp-research",
    "status": { "value": "Succeeded" },
    "subStatus": { "localizedValue": "OK (HTTP Status Code: 200)" },
    "subscriptionId": "",
    "httpRequest": {
      "method": "PUT",
      "uri": "https://management.azure.com/providers/microsoft.aadiam/diagnosticSettings/entra-timestamp-research?api-version=2017-04-01-preview"
    }
  }
]

The diagnostic-setting PUT began at 2026-08-08T16:47:50.443Z and completed successfully at 2026-08-08T16:47:51.584Z, as recorded by the BeginRequest and EndRequest eventTimestamp values. The Activity Log record itself has a submissionTimestamp of 2026-08-08T16:49:32Z. I use the successful EndRequest timestamp, 2026-08-08T16:47:51.584Z, as the diagnostic-setting write time in the analysis below.

Seven events tracked

I kept seven Entra interactive request IDs from August 8. IDs 1-3 are administrator portal sign-ins before the write. IDs 4-7 are timestamp-test-01 OfficeHome attempts 10-11 minutes after it. Interrupted rows (expired password, Keep me signed in) still have an Id; they are in the Entra catalog the same way successes are.

On 2026-08-08 at approximately 17:04 UTC, Entra Sign-in logs listed IDs 4-7 (timestamp-test-01, OfficeHome).

Figure 1 - Entra Sign-in logs, 2026-08-08 13:04 local (17:04 UTC). IDs 4-7 are the four timestamp-test-01 OfficeHome rows.

On 2026-08-08 at approximately 17:05 UTC a SigninLogs query for the last 24 hours returned no rows.

Figure 2 - SigninLogs in law-entra-timestamp-lab, last 24 hours, 2026-08-08 13:05 local (17:05 UTC). No rows.

The seven control IDs never arrived

I searched SigninLogs by those exact Id values. To do that programmatically I wrote a poller that queried the workspace every 5 minutes and compared each result set to the seven control IDs. It ran continuously through 2026-08-14. None of those seven IDs ever appeared. The first SigninLogs row the poller recorded had CreatedDateTime 2026-08-09T04:58:06.327Z: an administrator Azure Portal success (Id 6e691028-e113-4c40-a650-6bea27075400), not one of the August 8 controls. A 30-day exact-Id query on 2026-08-18 still returned nothing. The seven attempts remained in Entra.

Timestamp lag on rows that arrived

The first SigninLogs row had CreatedDateTime 2026-08-09T04:58:06.327Z. It appeared in the workspace at TimeGenerated 2026-08-09T04:59:45.960Z, about 12 hours and 12 minutes after the diagnostic-setting write. Microsoft documents that logs can take up to three days to start appearing after a diagnostic setting is configured. However, that activation delay does not explain the later absence of IDs 4-7: those attempts occurred 10-11 minutes after the successful diagnostic-setting write, remained present in Entra, and never appeared in SigninLogs, while later sign-ins from the same test user were ingested within about one to two minutes.

The test user was not excluded from export. Later OfficeHome attempts from timestamp-test-01 landed in SigninLogs in about one to two minutes, while the Aug 8 IDs for that same user were still listed in Entra and still absent from the workspace:

On rows that did arrive, ingest happened within the approximate range of between about 39 seconds to about 16 minutes in the snapshot I kept. IDs 1-3 are before the write, so a miss there is unsurprising. IDs 4-7 are after the successful diagnostic-setting write, still in Entra, and never appeared in the workspace. They were still absent after later SigninLogs rows began arriving. That is a coverage gap in this destination, not a latency measurement for those seven attempts.

The largest ingest lag in that snapshot was 978.4 seconds (16.3 minutes): administrator Azure Portal success Id ef75a488-45b1-4069-b411-4d37cd7e1700, CreatedDateTime 2026-08-10T16:39:53.825Z, TimeGenerated 2026-08-10T16:56:12.211Z. The smallest was 39.4 seconds. No SigninLogs row had a CreatedDateTime on 2026-08-08.

References

• Microsoft: How to configure Microsoft Entra diagnostic settings (https://learn.microsoft.com/en-us/entra/identity/monitoring-health/howto-configure-diagnostic-settings) (logs might take up to three days to start appearing in the destination)
• Microsoft: Sign-in logs in Microsoft Entra ID (https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-sign-in-log-activity-details) (definitions of sign-in timestamps including CreatedDateTime and TimeGenerated)
• Microsoft: Azure Monitor Logs reference - SigninLogs (https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/signinlogs) (SigninLogs table schema)

Tools used

The lab was configured and queried using Azure CLI, PowerShell, the Microsoft Entra admin center, and Azure Monitor Log Analytics.