Azure Activity Logs: Who Did What and When in Your Subscription

What activity logs capture

Every time something happens to an Azure resource at the management level — not inside the resource, but to the resource itself — an activity log entry is written. The types of events captured include:

• Resource creation: “Who created this virtual machine, and when?”
• Resource deletion: “Who deleted this resource group?”
• Resource modification: “Who changed the SKU of this App Service plan?”
• Role assignment changes: “Who was granted Owner on this subscription?”
• Policy assignment changes: “Who assigned this Azure Policy?”
• Secret writes to Key Vault: Only the metadata (who called SetSecret), not the secret value.
• Network security group rule changes: “Who added this inbound allow rule?”
• Subscription-level events: “Who registered this resource provider?”

Each entry records:

• operationName: The Azure Resource Manager operation that was called (e.g., Microsoft.Resources/resourceGroups/delete).
• status: Whether the operation succeeded, failed, or was accepted.
• caller: The identity that performed the operation — a user UPN, a service principal ID, or a managed identity.
• eventTimestamp: When the operation occurred.
• resourceId: The full ARM resource ID of the affected resource.
• subscriptionId, resourceGroupName, resourceType, resourceName: Parsed components of the resource ID.
• correlationId: A GUID linking related operations (useful for multi-step deployments).
• httpRequest: Client IP address, method, and request URI.

What activity logs do NOT capture

Understanding the boundary of activity logs is as important as understanding what they capture. Activity logs record control plane operations only. They do not record:

• Data plane operations: Reading a blob from storage, writing a row to SQL, sending a message to a queue. These are operations on the data inside the resource, not on the resource itself.
• What happened inside a VM: File access, process execution, network connections from inside the OS.
• Application logs: HTTP requests to your App Service, function invocations, application errors.
• Guest OS metrics: CPU, memory, disk I/O from inside a VM.
• Key Vault secret values: The activity log records that someone called GetSecret, but not the value returned.
• Microsoft Entra ID sign-in and audit events: These go to Entra ID audit logs, not Azure Activity Logs.

For data plane auditing (who read which secret, who accessed which blob), see the log types in Azure page, which covers resource diagnostic logs that capture data plane events for specific services.

Querying activity logs with the Azure CLI

The az monitor activity-log list command retrieves activity log entries. The most useful filters are time range, caller identity, resource group, and operation name.

Basic query: recent activity in a subscription

# List all activity log events in the last 24 hours
az monitor activity-log list \
  --start-time $(date -u -d '24 hours ago' '+%Y-%m-%dT%H:%M:%SZ') \
  --output table

Filter by resource group

az monitor activity-log list \
  --resource-group my-rg \
  --start-time $(date -u -d '7 days ago' '+%Y-%m-%dT%H:%M:%SZ') \
  --query "[].{Time:eventTimestamp, Caller:caller, Operation:operationName.value, Status:status.value}" \
  --output table

Filter by operation type (deletions only)

# List all delete operations in the last 7 days
az monitor activity-log list \
  --start-time $(date -u -d '7 days ago' '+%Y-%m-%dT%H:%M:%SZ') \
  --query "[?contains(operationName.value, 'delete') || contains(operationName.value, 'Delete')].{Time:eventTimestamp, Caller:caller, Operation:operationName.value, Resource:resourceId}" \
  --output table

Real-world query: who deleted a resource group in the last 7 days

This is a common incident response scenario. A resource group is gone and nobody admits to deleting it. The activity log has the answer.

# Find resource group deletion events in the last 7 days
az monitor activity-log list \
  --start-time $(date -u -d '7 days ago' '+%Y-%m-%dT%H:%M:%SZ') \
  --query "[?operationName.value=='Microsoft.Resources/resourceGroups/delete' && status.value=='Succeeded']" \
  --output json

This returns JSON entries. The key fields to examine in each entry are:

• caller: The identity that performed the deletion. This will be a user UPN (alice@contoso.com), a service principal object ID, or a managed identity identifier.
• eventTimestamp: The exact time the deletion completed (UTC).
• resourceGroupName: The name of the deleted resource group.
• httpRequest.clientIpAddress: The IP address from which the API call was made — useful for confirming whether it was from a known corporate IP, a CI/CD system, or an unexpected origin.
• correlationId: If the deletion was part of a larger automation run (Terraform destroy, deployment pipeline), multiple related operations will share this ID.

To narrow the search to a specific deleted resource group name (if you know the name):

# Find deletion of a specific resource group
az monitor activity-log list \
  --start-time $(date -u -d '7 days ago' '+%Y-%m-%dT%H:%M:%SZ') \
  --query "[?operationName.value=='Microsoft.Resources/resourceGroups/delete' && resourceGroupName=='my-deleted-rg' && status.value=='Succeeded'].{Time:eventTimestamp, Caller:caller, IP:httpRequest.clientIpAddress, CorrelationID:correlationId}" \
  --output table

If you see Succeeded in the status, the deletion completed. If you see Failed, someone attempted the deletion but was denied (perhaps by a lock or insufficient permissions) — that is also worth investigating.

Finding suspicious role assignment changes

Unexpected privilege escalation — someone granting themselves Owner or a highly privileged role — is a common attack pattern. Activity logs capture every role assignment creation and deletion.

# Find all role assignment creation events in the last 30 days
az monitor activity-log list \
  --start-time $(date -u -d '30 days ago' '+%Y-%m-%dT%H:%M:%SZ') \
  --query "[?operationName.value=='Microsoft.Authorization/roleAssignments/write' && status.value=='Succeeded'].{Time:eventTimestamp, Caller:caller, Resource:resourceId, IP:httpRequest.clientIpAddress}" \
  --output table

Look for:

• Role assignments made outside business hours.
• Role assignments made by accounts that should not be making them (developers granting themselves Owner).
• Role assignments at subscription scope (the resourceId will contain Microsoft.Authorization/roleAssignments at the subscription level).
• Multiple role assignments in quick succession from the same caller (bulk privilege escalation).

For more advanced detection of suspicious patterns, including KQL queries in Log Analytics, see detecting suspicious activity in Azure.

Exporting activity logs to Log Analytics

The 90-day native retention limit means that for long-term compliance, historical investigation, or KQL-based alert rules, you need to export activity logs to a Log Analytics workspace.

# Get the Log Analytics workspace resource ID
WORKSPACE_ID=$(az monitor log-analytics workspace show \
  --workspace-name my-workspace \
  --resource-group my-rg \
  --query id \
  --output tsv)

# Get the subscription resource ID
SUBSCRIPTION_RESOURCE_ID="/subscriptions/$(az account show --query id --output tsv)"

# Create a diagnostic setting to export activity logs to Log Analytics
az monitor diagnostic-settings create \
  --name "activity-logs-to-law" \
  --resource "$SUBSCRIPTION_RESOURCE_ID" \
  --workspace "$WORKSPACE_ID" \
  --logs '[
    {
      "category": "Administrative",
      "enabled": true
    },
    {
      "category": "Security",
      "enabled": true
    },
    {
      "category": "Alert",
      "enabled": true
    },
    {
      "category": "Policy",
      "enabled": true
    }
  ]'

Activity log categories available for export:

• Administrative: CRUD operations on all resources. This is the most important category.
• Security: Azure Security Center alerts.
• Alert: Azure Monitor alert activations.
• Autoscale: Autoscale engine actions.
• Policy: Policy evaluation results (compliance state changes).
• Recommendation: Advisor recommendations.

Once exported to Log Analytics, events are queryable using KQL in the AzureActivity table. For an overview of all Azure log types and where they go, see log types in Azure.

Using activity logs to investigate resource lock bypasses

Azure resource locks (ReadOnly and CanNotDelete) prevent accidental deletion. When a lock is deleted, the activity log captures it, giving you an audit trail if someone removed a lock before deleting a resource.

# Find lock deletions in the last 30 days
az monitor activity-log list \
  --start-time $(date -u -d '30 days ago' '+%Y-%m-%dT%H:%M:%SZ') \
  --query "[?operationName.value=='Microsoft.Authorization/locks/delete' && status.value=='Succeeded'].{Time:eventTimestamp, Caller:caller, Resource:resourceId}" \
  --output table

If you see a lock deletion immediately followed by a resource deletion (close timestamps, same caller), that is a pattern worth investigating. The correlationId may link the two events if they were part of the same automation run.