I was working with a customer recently who was trying to track down changes across several subscriptions. Nothing unusual there, except we quickly realized something was missing. A number of subscriptions were not sending Azure Activity Logs to Microsoft Sentinel at all. No errors, no alerts, just silent gaps.
It stood out because this is one of those data sources I have consistently found to be useful, especially when you need to answer two very practical questions:
What changed?
Who owns or is actively working on this resource?
In most cases, Azure Activity Logs make both answers straightforward.
What Azure Activity Logs Actually Are
Azure Activity Logs capture control plane operations across your subscriptions. This includes things like:
- Resource creation, updates, and deletions
- Role assignments and access changes
- Policy changes
- Service-level operations
Each record includes the identity behind the action, which can be:
- A named user
- A service principal
- A managed identity
- A guest or B2B account
That last point is important. External users and contractors often have meaningful access, and Activity Logs give you clear visibility into what they are doing.
A Few Practical Tips
1. Send Activity Logs to Sentinel
There is little downside here:
- No ingestion cost
- Immediate value for investigations and reporting
This is one of the easiest wins available.
2. Max Out Interactive Retention
This is one of the rare cases where extended retention is easy to justify.
For the AzureActivity table, you can:
- Set interactive (analytics) retention to 730 days (2 years)
- Do this without additional cost for this data source
That gives you a long, fully searchable history for:
- Investigations
- Audits
- Historical change tracking
How to set it:
- Go to Log Analytics workspace
- Select Tables
- Choose AzureActivity
- Set Total retention = 730 days
- Keep data in the Analytics tier
3. Verify Coverage Across All Subscriptions
Azure Activity Logs in Sentinel are typically collected using an Azure Policy-based data connector, which deploys diagnostic settings across subscriptions.
Because all data lands in the same AzureActivity table, it can give the impression that everything is covered when it is not. In larger tenants, it is easy for a few subscriptions to be missed or fall out of scope over time.
It is a good idea to periodically verify that all subscriptions are actually sending data.
A simple way to check:
AzureActivity
| where TimeGenerated > ago(700d)
//| where SubscriptionId == "e1edeed0-cfb3-4744-94d7-cee4424bcd62"
| summarize count() by SubscriptionId
| count
This gives you the number of subscriptions currently reporting data. If it is lower than expected, you likely have gaps.
4. Quickly See Who Is Making Changes
When you want a fast view of who is actually doing work in your environment, a simple summary goes a long way.
This example focuses on human users by filtering on callers that contain @:
AzureActivity
| where TimeGenerated > ago(30d)
| where Caller contains "@"
| summarize count() by Caller, OperationName
| sort by count_ desc
This gives you a quick breakdown of:
- Who is active across the environment
- What types of changes they are making
- Whether any unexpected users are showing up
The Caller field represents the identity used for the operation when it is recorded, and OperationName reflects the activity performed. Together, this gives a clear view of who is doing what.
Closing Thought
Azure Activity Logs are not new, and they are not complex. But they are one of the most consistently useful datasets in Azure.
When something changes and you need to understand what happened, they are often the first place to look. And when they are missing, you notice.