The Missing Signal in Cloud Orphan Detection: Azure Activity Log

If you have used a cloud cost tool for more than a quarter, you have seen the same pattern: the same "maybe orphaned" resources show up on every report, and your team never actually deletes them. The reason is not laziness — it is that the tools you are looking at do not give you enough confidence to act. They tell you a VM is stopped or a disk is unattached, but not whether someone might still need it.

There is a signal that fixes this, it is free, and it is sitting in every Azure subscription right now. Almost no cost tools use it.

Azure Activity Log: the strongest orphan signal nobody reads

The Activity Log is Azure's record of every control-plane write in a subscription — every create, update, delete, role assignment, and configuration change. It goes back 90 days for free. For orphan detection, it answers the one question every other signal misses:

• "When was this resource last touched by anyone?"

A VM that has been stopped for 30 days, with no metrics activity, and no admin write operation in 90 days is a high-confidence orphan. A VM that has been stopped for 30 days but had a config change yesterday is almost certainly someone reactivating it manually. Same metadata, different story — and only Activity Log can tell you which.

Why most tools skip it

• Volume. A busy subscription generates hundreds of thousands of activity entries a month. You have to aggregate and bucket them per resource — that is real work compared to just reading resource metadata.
• Cardinality. Operation names and categories vary by service, so a generic "last touched" query has to handle dozens of patterns to be useful.
• It is easier to ship a "stopped VM" check than to add a 90-day rolling activity rollup. So most tools ship the easy check and call it done.

What changes when you use it

Pairing Activity Log with the signals you already have changes orphan detection from "here is a list to review" to "here is a list to act on":

• Stopped VM + no writes in 90 days + zero metrics → safe to delete, high confidence.
• Stopped VM + recent admin write → someone is still touching it; flag but do not delete.
• Unattached disk + never written to since creation → almost certainly forgotten by whoever provisioned it.
• Storage account + no transactions + no role assignment changes in 90d → an audit-confident deletion candidate.

The point is not that Activity Log replaces the other signals — it is that it lets the confidence score on each recommendation actually mean something. Without it you are guessing. With it you can tell an engineer "no one has touched this resource in 87 days, delete it" and get nodded through the change.

How CloudRift uses it

CloudRift pulls 90 days of Activity Log alongside every scan and computes a per-resource "last touched" date and recent write count. Resources with idle activity get tagged automatically, the signal flows straight into the confidence score, and every recommendation cites it explicitly — so when you see "Confidence: Very High" on a delete suggestion, you can hover and read "Last touched 87 days ago — no writes in 90d" as the reason.

It is one of those upgrades that is invisible if it is not there and obvious the moment it is.

The bottom line

Activity Log is the strongest, cheapest, most underused signal in cloud orphan detection. If your cost tool does not look at it, you are flagging the same maybe-orphans every month and nobody is acting on them. Bring in the "last touched" data and the work changes from review to remediation — which is the whole point.