Azure Monitor Activity Log
Query Azure Monitor Activity Log events and retrieve category metadata for one subscription using delegated Microsoft OAuth.
Verdict
Common use cases
- Audit who deleted a production resource
- Trace deployment failures in the last 24 hours
- Review policy violations across the subscription
- Investigate access changes during an incident
- Export event categories for compliance reporting
Integration
- Vendor
- Azure Monitor Activity Log
- Category
- other
- Auth
- OAUTH2
- Tools
- 2
- Composio slug
azure_monitor_activity_log
Tools
- List Activity Log Events
Return one page of Activity Log events for a UTC time range from the subscription selected when the Azure connection was created. Legacy connections missing that selection work only when exactly one subscription is visible; otherwise reconn
- List Event Categories
Return the Activity Log event categories recognized by Azure, including their localized labels when available.
Setup
Setup guide
- 11. In Switchy, open your workspace settings and navigate to the Integrations page. 2. Find Azure Monitor Activity Log in the catalog and click Connect. 3. You'll be redirected to Microsoft's OAuth consent screen — sign in with an Azure account that has read access to the subscription you want to monitor. 4. Grant the requested permissions (typically 'Read activity logs' scope). 5. On the callback screen, select the specific Azure subscription you want this connection to query; if you skip this step and have multiple subscriptions, the connection won't work. 6. Back in Switchy, create or open a Project and type '@Azure Monitor Activity Log list events from the last hour' to confirm the connection returns data. 7. If you see events, you're ready; if you get an error about multiple subscriptions, revisit the integration settings and choose one.
What teammates see: by default, memories from Azure Monitor Activity Log are scoped to the Project (PROJECT visibility) - you can mark any memory PRIVATE or share it ORG-wide.
Works well with
Top models
Compatibility data appears once enough Projects have used this MCP together with a given model.
How Switchy teams use it
Starter prompts
Recent Deployment Failures
@Azure Monitor Activity Log list all activity log events from the past 6 hours where the status is 'Failed' and the category is 'Administrative', then summarize which resources were affected and what the error messages say.
Resource Deletion Audit
@Azure Monitor Activity Log show me all delete operations in the activity log from the last 24 hours, including the caller identity and the resource that was removed.
Policy Violation Report
@Azure Monitor Activity Log fetch events from the past week where the operation name contains 'Policy' and the status is 'Failed', then group them by policy name and count occurrences.
Access Change Timeline
@Azure Monitor Activity Log retrieve all role assignment and authorization events from yesterday, then create a timeline showing who granted or revoked access and to which resources.
Event Category Reference
@Azure Monitor Activity Log list all available event categories with their localized labels, then format them as a markdown table so I can reference them later.
Example outputs
Illustrative - representative of the model's voice and quality, not literal recordings.
@Azure Monitor Activity Log show me all administrative operations that happened in our subscription in the last 24 hours
Retrieved 47 Activity Log events from the past 24 hours. Administrative operations include: 3 resource group creations (prod-api-rg, staging-db-rg, dev-frontend-rg), 2 role assignments (Contributor role granted to engineering@company.com on prod-api-rg), 1 storage account deletion (old-logs-storage), and 5 virtual machine start/stop operations. Most activity occurred between 14:00-16:00 UTC during the deployment window. All operations completed successfully except one failed VM resize attempt at 15:23 UTC.
This example shows read-only event retrieval across a subscription. The MCP returns one page of results (typically 50-200 events depending on activity volume). If your Azure connection predates subscription selection, you must have exactly one subscription or the query will fail. No write operations are exposed—this MCP is purely observational.
@Azure Monitor Activity Log what event categories does Azure track, and which ones should we monitor for security incidents?
Azure recognizes 7 Activity Log categories: Administrative (resource CRUD operations), Security (alerts from Defender for Cloud), ServiceHealth (planned maintenance, incidents), ResourceHealth (VM availability changes), Alert (metric/log alert firings), Autoscale (scale-out/in events), and Recommendation (Advisor suggestions). For security monitoring, focus on Administrative (unauthorized access attempts, privilege escalations) and Security (threat detections, vulnerability findings). ServiceHealth is critical for incident response planning but not directly security-related.
This example uses the event categories tool to explain Azure's taxonomy. The AI synthesizes which categories matter for a security use case—something the raw API doesn't provide. Useful for onboarding teammates who need to understand what Activity Log captures before writing alert rules or compliance reports.
@Azure Monitor Activity Log compare resource creation activity this week versus last week and flag any unusual spikes
Week-over-week comparison of Administrative category events with 'Create' operations: Last week (Dec 2-8): 23 resource creations averaging 3.3/day. This week (Dec 9-15): 61 resource creations averaging 8.7/day, a 165% increase. Spike occurred on Dec 12 with 19 creations in a single day—primarily storage accounts (12) and app service plans (5) in the dev-testing-rg resource group. This aligns with the new microservices POC mentioned in #engineering-updates. No deletions followed these creations yet, suggesting active experimentation rather than cleanup churn.
This example chains two time-range queries and asks the AI to interpret the delta. The MCP itself has no comparison logic—the AI performs the analysis. Requires two separate API calls (one per week), so expect 2-4 seconds of latency. Useful for cost anomaly detection or shadow IT discovery, but remember Activity Log retention is 90 days maximum.
Use-case deep-dives
When Azure Monitor Activity Log beats manual audit trails
A 6-person DevOps team at a SaaS company needs to reconstruct what happened during a 2am production outage. The Activity Log MCP pulls subscription-level events for the incident window—VM restarts, network config changes, role assignments—without switching contexts from Switchy to the Azure portal. This works because the MCP's OAuth2 flow scopes to one subscription at setup, so the team sees only their prod environment's timeline. The trade-off: if you manage multiple subscriptions or need cross-tenant visibility, you'll hit the single-subscription limit and need separate connections. For teams running one Azure subscription per environment, this MCP turns a 20-minute portal hunt into a 90-second Switchy query during the post-mortem.
Why this MCP matters for SOC 2 readiness
A 3-person startup preparing for its first SOC 2 audit needs to prove who changed what in Azure over the last 90 days. The Activity Log MCP surfaces subscription events—resource deletions, policy updates, access grants—in Switchy's shared workspace, so the founder and fractional auditor review the same timeline without credential handoffs. The two-tool scope (list events, list categories) is narrow but sufficient: you're not analyzing metrics or logs, just proving change control. The limit: if your auditor needs events older than Azure's 90-day retention, the MCP can't help—you'd need Log Analytics or a third-party archive. For early-stage teams hitting compliance checkboxes, this MCP closes the 'who did what' gap without buying a full SIEM.
When Activity Log context speeds up FinOps triage
A 4-person finance team at a mid-market company sees an unexpected $8k Azure bill spike and needs to know which resources were created or scaled that week. The Activity Log MCP lists subscription events filtered by time range, surfacing VM deployments, storage account creations, and scale-set changes alongside the cost anomaly. This works because Activity Log captures control-plane actions—the 'what got spun up' layer—not the usage metrics themselves. The boundary: if the spike came from existing resources running hot (CPU, bandwidth), you need Azure Monitor metrics, not Activity Log. For teams where finance owns cost accountability but lacks Azure portal access, this MCP puts the 'who deployed what' context in Switchy's shared space, cutting triage time from hours to minutes.
Frequently asked
What does the Azure Monitor Activity Log MCP do in Switchy?
It pulls Azure subscription-level activity logs — who did what, when — into your AI workspace. You can query events by time range, filter by category, and surface audit trails without leaving Switchy. It's read-only: you can't write logs or change Azure resources through this MCP.
Do I need admin access to connect Azure Monitor Activity Log?
You need Reader access on the Azure subscription you want to monitor. The OAuth flow asks for permissions to read activity logs and subscription metadata. If your legacy connection predates subscription selection, it only works when your account has exactly one subscription.
Can this MCP filter logs by resource group or specific Azure services?
No. It returns subscription-wide events for a UTC time range and lets you see event categories, but it doesn't filter by resource group, service type, or severity out of the box. You'd need to parse the returned events in your AI workflow to narrow results further.
How is this different from using Azure Portal or the Activity Log API directly?
Same data, faster access inside Switchy. You skip context-switching to the Azure Portal and can pipe log events straight into AI analysis or incident reports. The trade-off: you lose the Portal's built-in visualisations and advanced query editor.
Who on the team should connect the Azure Monitor Activity Log MCP?
Whoever owns Azure subscription access and needs to audit deployments, permission changes, or resource failures. Typically a DevOps lead or platform engineer. One connection per subscription is enough; the whole team can query it once connected.