Skip to content

Office 365 and Azure Data Availability🔗

This page explains:

  • How Secureworks® Taegis™ XDR polls Microsoft APIs.
  • Which timestamp drives collection versus event time in the product.
  • When a gap between event time and ingest time is expected.

Event Time vs. Ingest Time🔗

When analyzing events, event time typically refers to when Microsoft (or the export) says the activity occurred. Ingest time is when the normalized event for that row is created in XDR, i.e. when the ingest (normalization) for that row is complete. Ingest time is not when every downstream step finishes; detectors, alerts, investigations or cases, automation, and similar workflows can still run after ingest time. A large gap between event time and ingest time is often expected when Microsoft publishes or updates the record later, when polling has not yet reached that time window, or when search indexing is still catching up (see Platform delay after collection).

Term Meaning
API time field A timestamp Microsoft uses so each poll can ask for “what changed in this time range” (for example lastUpdatedDateTime or createdDateTime in the Graph API). It controls when a row becomes eligible to download, not necessarily what you see as event time.
Event time (in the UI; in raw exports sometimes event_time_usec) When the underlying activity occurred, taken from vendor fields such as activityDateTime or createdDateTime, depending on source—not necessarily the same as the API time field.
Ingest time (in the UI; in raw exports sometimes ingest_time_usec) When the normalized event is created, i.e. when the ingest (normalization) for that row is complete. Later product behavior, such as alerts, investigations, and automation, can still occur after this timestamp.
Availability time When present, often closer to the vendor’s last modified or updated time than to the original activity (for example on risk detections that use lastUpdatedDateTime).

Some reasons why the event time and ingest time differ:

  1. Vendor delay — Microsoft may expose a log only minutes or hours after the activity, or update the same record later as part of remediation or alert refresh. Ingest follows API visibility and updates, while event time often stays tied to the original activity.
  2. Polling and lag — Collection runs on a schedule and uses intentional lag behind "now", so late-arriving data is still captured. Multiple parallel streams with different lag lookbacks are common.
  3. Platform pipeline — Transfer, batching, and indexing add additional minutes before data appears in search.

How to Interpret an Event🔗

When investigating a large event time vs. ingest time gap:

  1. Identify which Microsoft integration produced the event (Graph sign-in, risk detection, Management API, Azure Activity, etc.), then use the integration tables under Microsoft Graph API, Office 365 Management Activity API, Azure Monitor REST API (polling), and Azure Activity and Microsoft Graph activity logs (non-polling integrations) to see which vendor fields map to event time versus what drives each collection cycle (or export cadence).
  2. If you have original or vendor JSON, compare the activity or creation timestamps to lastModified / lastUpdated / lastUpdate (exact names depend on the API).
  3. If “updated” is much later than “activity”, the row was likely ingested when Microsoft published that revision, not when the sign-in or activity first occurred.
  4. If both are close but ingest is still much later, consider polling interval and lag, Microsoft throttling, and downstream delay (including search indexing).

Microsoft Graph API🔗

Collection uses scheduled requests to Microsoft Graph API. Each request asks for records in a time range, using the API time field listed below. The collector applies lag behind the current time, limits how large each range can be, and may run parallel streams with different lookbacks, so late-arriving rows are still captured.

Integrations, API Filter Field, and Event Time Mapping🔗

Integration Graph resource (list) API time field (drives polling) Typical source of event time
Microsoft Risk Detection; Microsoft Entra ID Protection (Identity XDR) — user risk detections .../identityProtection/riskDetections lastUpdatedDateTime activityDateTime
Microsoft Entra ID Protection — service principal risk detections .../identityProtection/servicePrincipalRiskDetections lastUpdatedDateTime activityDateTime
Microsoft Entra ID Protection — agent risk detections (beta) .../identityProtection/agentRiskDetections (beta) lastModifiedDateTime activityDateTime
Microsoft Graph — sign-ins .../auditLogs/signIns createdDateTime createdDateTime
Microsoft Graph — directory audits .../auditLogs/directoryAudits activityDateTime activityDateTime
Microsoft Graph Security — alerts (legacy) .../security/alerts lastModifiedDateTime eventDateTime, or firstActivityDateTime, or createdDateTime (in that order when a field is missing)
Microsoft Graph Security — alerts v2 .../security/alerts_v2 lastUpdateDateTime eventDateTime, or firstActivityDateTime, or createdDateTime (in that order when a field is missing)

Note

For some resources, the API time field is a last modified/updated timestamp, while event time in XDR comes from when the activity or incident started (for example, activityDateTime, eventDateTime, or firstActivityDateTime, depending on the API). Risk detections, Graph Security alerts (legacy and v2), and other mutable objects can change hours later when Microsoft applies remediation, status changes, or refreshes. That bumps the update field and can drive a new ingest, even though event time still reflects the original activity.

Typical Poll Intervals🔗

These values are typical for Microsoft Graph collection. Deployed intervals can differ by environment and may change over time as availability and rate limits evolve.

Legacy vs. current Graph Audit (sign-ins / directory audits)

The legacy integration completed consent against a Secureworks-managed shared application, so Microsoft Graph saw one shared client across many tenants and tighter effective throttling. Collection was tuned with fewer streams and a longer base poll interval than current Graph Audit, where each tenant uses its own application registration and polling can run more often with more parallel lag streams.

Integration Typical interval (minutes) Notes
Microsoft Graph — sign-ins / directory audits (legacy shared application) 10 Two streams per API (sign-ins and directory audits each): one with lag on the order of 10 minutes, one long lookback on the order of 4 hours (~250 minutes). Superseded for new setups by tenant-application Graph Audit.
Microsoft Graph — sign-ins / directory audits (tenant application) 1 Multiple streams with lag lookbacks (e.g. 1, 10, 20, ... 50 minutes) and optional start offset; additional streams may poll on a 10-minute cadence for longer lookbacks (up to several hours).
Microsoft Graph — sign-ins / directory audits (Identity XDR) 1 Similar multi–lag stream pattern to tenant-application Graph Audit.
Microsoft Risk Detection; Entra ID Protection user risk detections 5 Includes extra lookbacks (e.g. 4-hour stream).
Microsoft Graph Security — alerts (legacy) and alerts v2 10 Usually a near-real-time stream plus a long lookback stream (e.g. lag 250 minutes).
Microsoft Entra ID Protection — service principal and agent risk detections 5 Same general pattern as user risk.

Office 365 Management Activity API🔗

Audit content from the Office 365 Management Activity API is normalized for search and analytics in XDR. The same subscription, listing, and retrieval pattern applies across offerings; what changes is mainly the activity feed host Microsoft assigns for commercial vs. government clouds, and whether the tenant uses the current (customer Entra ID application + certificate) onboarding or an older legacy flow.

For integration setup (permissions, certificates, GCC vs commercial), see Office 365 Management API.

Listing, Content URIs, and Delayed Publication🔗

Microsoft describes collection as a two-step flow:

  1. Discover blobs — After a subscription is started for a content type (for example, Audit.AzureActiveDirectory), the client either lists available content (for example, /subscriptions/content with optional startTime / endTime) or receives a webhook when new blobs are ready. Each item includes a contentUri, contentCreated (when Microsoft made that aggregation available), and related metadata.
  2. Download events — The client issues a GET to each contentUri to retrieve the JSON actions and events inside that blob.

A blob appearing in the list means that aggregation is ready to download; individual events inside the blob can still be delayed relative to when the activity actually occurred, and blobs are not guaranteed to appear in the same order as real-world event order. That is why event time (typically each record’s CreationTime) can be much earlier than ingest time. For Microsoft’s wording on aggregation, listing, retrieval, and latency, see Additional Resources below.

Integrations, Listing Window, and Event Time Mapping🔗

Integration Microsoft activity feed base URL What drives each collection cycle Typical source of event time
Office 365 Management — commercial / enterprise Microsoft 365 https://manage.office.com/api/v1.0/{tenant_id}/activity/feed/... Start a subscription per content type; list blobs with /subscriptions/content using startTime / endTime on when the blob became available (see Microsoft’s contentCreated in the list response); GET each contentUri. Uses a customer-registered Entra ID application and certificate. CreationTime on each audit record
Office 365 Management — GCC https://manage-gcc.office.com/api/v1.0/{tenant_id}/activity/feed/... Same subscribe → list → GET contentUri model; GCC endpoint for Microsoft 365 Government — GCC. Customer app + certificate in the government tenant. CreationTime
Office 365 Management — GCC High https://manage.office365.us/api/v1.0/{tenant_id}/activity/feed/... Same model; GCC High endpoint and sovereignty rules per Microsoft. Customer app + certificate. CreationTime
Office 365 Management — legacy https://manage.office.com/... (same API shape as commercial) Same blob semantics; older XDR product line predating the current register your own Entra ID application + certificate flow documented for commercial/GCC (analogous to legacy vs tenant-application Microsoft Graph Audit). Not offered for new integrations; polling is less aggressive than modern customer-app commercial. CreationTime
Microsoft 365 Identity XDR — Office 365 Management path Commercial-style host for the customer tenant Same Management Activity API and customer-tenant credentials; Entra app registration may be provisioned automatically as part of XDR onboarding rather than pasted in manually. CreationTime

Typical Poll Intervals🔗

These values are typical; deployed timings can differ by environment and may change over time.

Why this table is less specific than Microsoft Graph

The Graph section lists minute-level intervals that match shipped stream configuration for those integrations. Office 365 Management integrations also use platform-defined poll intervals and lookbacks, but representative numbers are not documented here to the same level of precision as Graph for this page. Behavior is still scheduled polling: each pass lists content blobs using startTime / endTime tied to blob availability (see Microsoft’s List available content), then downloads each contentUri, so the cadence governs how often those listing windows advance, not the CreationTime inside each event.

Integration Typical cadence Notes
Office 365 Management — commercial, GCC, GCC High, Identity XDR (Management path) Frequent listing passes (often about one minute apart) startTime / endTime apply to blob availability, not to each event’s CreationTime. Lookbacks re-cover prior windows so late-published blobs are still picked up. Tuned for Microsoft throttling and tenant size.
Office 365 Management — legacy Less frequent than customer-app commercial Older collector layout and onboarding model; superseded by customer Entra app integrations for new tenants.

Azure Monitor REST API (Polling)🔗

The polling integration calls the Azure Monitor Activity Logs - List API per linked subscription. Each run requests events in a time window filtered on eventTimestamp (Microsoft may expose additional filter parameters). Collectors also re-query earlier windows (for example, several hours in the past) because Microsoft can publish or correct Activity Log rows after the fact, similar to lookbacks used for Graph and Office 365 Management.

Authentication uses delegated permissions and operates on behalf of a configured user; see Microsoft Azure Activity Log.

Integrations, API Filter Field, and Event Time Mapping🔗

Integration API (list) Time field (drives polling) Typical source of event time
Azure Activity Log — Monitor REST (polling) Activity Logs - List (.../providers/microsoft.insights/eventtypes/management/values) eventTimestamp (query window bounds) eventTimestamp, or time if eventTimestamp is missing

Microsoft Graph activity logs are normally enabled through diagnostic export to Event Hub (or another sink), not through this List API path; when present in the exported stream, event time still maps from eventTimestamp / time as above.

Typical Poll Intervals🔗

These values are typical for the REST Activity Log integration; deployed timings can differ by environment.

Integration Typical interval (minutes) Notes
Azure Activity Log — Monitor REST (polling) 5 Multiple parallel streams, each running on a 5-minute cadence with different lag lookbacks behind “now” when querying eventTimestamp (for example 5, 10, 15, 20, 25, 30, 60, 90, 120, and 240 minutes). Max lookback per stream is sized so late-published or corrected rows are still captured, subject to Microsoft rate limits.

Azure Activity and Microsoft Graph Activity Logs (Non-Polling Integrations)🔗

XDR can ingest Azure Activity (subscription-level Azure control-plane audit) and Microsoft Graph activity (Graph API request audit for the tenant) through diagnostic export (Event Hubs, storage, or similar)—the path this section covers. Azure Activity Log can instead be collected via REST polling; timing and API fields for that path are in Azure Monitor REST API (Polling). Setup for export and polling is described in Microsoft Azure Activity Log.

Diagnostic Export (Event Hubs, Storage, etc.)🔗

With Azure Monitor diagnostic settings, you send selected categories to an Event Hub, storage account, or other supported sink. XDR consumes those streams or files; there is no fixed poll interval from our side—cadence and batching follow Azure and your diagnostic configuration.

Event time is taken from vendor fields such as eventTimestamp or time in the payload (exact names depend on category and format). Microsoft Graph activity log records use the same general pattern when exported through Monitor (top-level time and related properties).

Platform Delay after Collection🔗

After the API returns data:

  • Handoff between components is usually under a minute, but may be longer under load.
  • Batched writes and indexing can add tens of minutes before events are searchable; detectors may run before search is available.

These effects widen ingest time vs. vendor timestamps even when polling is healthy.

Content Integrity🔗

Query parameters are used only to retrieve data; they do not rewrite vendor JSON. Raw content is preserved (e.g. in original_data). If vendor JSON is malformed (invalid structure or syntax) or too sparse (for example, missing fields or values you need for investigation) raise that with Microsoft, since XDR does not control how Microsoft builds the payload.

Additional Resources🔗

Office 365 Management Activity API (blobs, listing, retrieval, delay)

Other