Tracking Azure Resource Changes: Answering "What Changed?" Before the Trail Expires

The storage account worked fine yesterday. This morning the app is throwing 403s, on-call is two coffees deep, and the incident channel has already asked the only question that matters: what changed?

Azure knows the answer. Somewhere in the Activity Log there is a write operation against that storage account, timestamped 11:47 PM, with a caller attached. Getting to it is the hard part: pick the right subscription, filter out the reads and health probes, expand JSON payloads one event at a time, and hope the change you're hunting didn't happen 91 days ago.

The Problem: Azure Remembers Operations, Not State

The Activity Log is a record of API calls. An entry tells you that Microsoft.Storage/storageAccounts/write succeeded at 11:47 PM and who called it. It does not show you what the resource looked like before, what it looks like now, or which of its forty properties actually moved. Incidents and audits need a record of infrastructure state, and Azure's native tools only approximate one:

• Retention is short. The Activity Log keeps 90 days of events unless you set up an export pipeline to Log Analytics or storage. The Resource Graph change feed keeps far less.
• Scope is per subscription. Building a timeline across an environment means merging queries or exports from every subscription involved.
• The diff is on you. Even when you find the right event, reconstructing "port 443 was open, now it isn't" from an operation name is guesswork.

So the question "what changed?" has two failure modes: the trail exists but takes an hour to assemble, or the trail has already expired.

Pulling the Timeline by Hand

For recent, single-scope questions, the CLI gets you the raw events:

az monitor activity-log list \
  --resource-group rg-prod-eastus \
  --start-time 2026-06-20T00:00:00Z \
  --query "[].{time:eventTimestamp, operation:operationName.localizedValue, caller:caller}" \
  --output table

For cross-subscription questions, Azure Resource Graph has a resourcechanges table that is genuinely better than most people realize. It records creates, updates, and deletes with property-level change details:

resourcechanges
| extend changeTime = todatetime(properties.changeAttributes.timestamp),
         changeType = tostring(properties.changeType),
         targetId = tostring(properties.targetResourceId),
         changedBy = tostring(properties.changeAttributes.changedBy)
| where changeTime > ago(7d)
| project changeTime, changeType, targetId, changedBy
| order by changeTime desc

That query runs in Resource Graph Explorer across every subscription you can read, and it is the fastest manual answer to "what changed this week?" that Azure offers.

Both tools earn a bookmark. But look at what they leave you holding:

1. The trail expires. Activity Log events age out at 90 days; resourcechanges keeps roughly 14 days of history (check the current window for your environment). If the bad change landed last month, neither can show it to you.
2. You get the operation, not the picture. Property changes arrive as JSON fragments per event. Reading them one resource at a time works; reading them across an incident does not.
3. There is no full before and after. Neither tool can show you the complete state of a resource as it existed last Tuesday, next to its state today.
4. Correlation is manual. Turning raw events into an incident timeline, across teams and subscriptions, is a copy-paste job that happens under pressure.

How StratoLens Keeps the Whole Timeline

StratoLens takes a different approach to the same question: instead of logging operations, it captures a full snapshot of your infrastructure on every scan. That flips each gap above:

• History lasts as long as your snapshots do. The timeline is not capped at Azure's 90-day or 14-day windows; you can compare against last quarter, not just last week.
• Side-by-side diffs. Changes render as property-level comparisons with the old value and the new value, not JSON fragments to decode.
• Complete before and after. Because every scan is a full snapshot, you can see the entire resource as it existed at either point in time, not just the fields an event happened to mention.
• Compare any two points in time. Pick two scans and get everything created, modified, or deleted between them, across all subscriptions, with who-changed-it attribution correlated from the Activity Log.

The snapshots themselves live inside your own Azure tenant, in your subscription. The audit trail StratoLens builds never leaves your control.

Build the Timeline Before You Need It

The worst time to discover a retention window is during an incident. Keep the resourcechanges query above bookmarked, and consider exporting your Activity Log somewhere durable regardless of what tooling you use. If you would rather have the full state history captured continuously, with diffs and attribution ready before anyone asks "what changed?", that is exactly what Change Tracking in StratoLens does.