Cost

Trim classic Storage Analytics log retention

Classic Storage Analytics logging writes request logs into a hidden $logs container on every account that has it switched on. With no retention policy, those logs accumulate forever and you pay to store them. Setting a sensible retention period lets Azure delete stale logs automatically and stops a silent line item growing on the bill.

12 min·10 sections·AZURE

Last reviewed 18 June 2026

Classic log retention: the basics

Why do old storage logs quietly cost money?

Classic Storage Analytics logging is the older, account-level diagnostic feature that records read, write and delete requests for the Blob, Queue and Table services. When it is enabled, Azure writes one log entry per request into a hidden blob container named '$logs' inside the same storage account. On a busy account that is a steady stream of small log blobs, and they are charged at the account's normal blob storage rate, the same as any other data you keep.

The catch is the retention policy. Classic logging has an optional 'delete data' setting that tells Azure how many days of logs to keep. If that policy is not set, there is no automatic cleanup: Azure keeps every log blob indefinitely and it is left to you to delete them. Accounts that were created or configured before a retention policy was a habit often have logging on and retention off, so the '$logs' container has been growing for years without anyone looking at it. Because '$logs' is hidden from the normal portal container view, the growth is easy to miss entirely.

Azure Advisor surfaces this as the recommendation 'Revisit retention policy for classic log data in storage accounts' (Recommendation ID 386452d3-8df0-4174-94cb-fee063b3084f), under the Cost category. It is flagging accounts where classic log data is piling up so you can decide how long you genuinely need to keep it. The fix is to set a retention period that matches what you actually use, after which Azure deletes stale logs for you and the line item stops climbing.

In this lesson you will learn what classic Storage Analytics logging stores, why missing retention policies turn it into an ever-growing storage charge, how to find the accounts Advisor has flagged, and how to set a sensible retention period so Azure prunes stale logs for you. You will also see when to retire classic logging altogether in favour of Azure Monitor.

Fun fact

The container the portal will not show you

The '$logs' container that classic logging writes to is special: it is hidden from the standard container list in the Azure portal and from the storage browser. For classic storage accounts it only appears in tools like Azure Storage Explorer or through the storage APIs. That invisibility is exactly why these logs grow for years without anyone noticing. The data is sitting there being billed every month, but unless you go looking with the right tool, the portal acts as though the container is not there at all.

Finding accounts with unbounded classic logs

Priya runs the platform team at a company doing its annual cloud cost review. Azure Advisor's Cost tab lists several storage accounts under 'Revisit retention policy for classic log data in storage accounts'. She wants to see which accounts have classic logging on, and crucially which have no retention policy set, before changing anything.

Rather than open each account in the portal, where the '$logs' container is hidden anyway, she checks the logging settings directly so she can tell drift from deliberate configuration in one pass.

Show the classic logging settings for an account across all three services. A retention of 0 means logging is on but nothing is ever deleted.

$ az storage logging show --account-name logsheavyprod --services bqt -o table

Service Read Write Delete RetentionPolicy.Days

--------- ------ ------- -------- ---------------------

blob True True True 0

queue True True True 0

table False False False 0

# blob and queue log every request with NO retention: $logs grows forever.

Retention of 0 with logging on is the costly state: every request is logged and nothing is ever pruned. This is the account to fix first.

How classic logging accrues costdeep dive

Classic logging is a data-plane setting on the storage account, separate from the modern diagnostic settings that send data to Azure Monitor. For each of the Blob, Queue and Table services you can enable logging of read, write and delete operations independently, and each enabled operation writes log entries into the '$logs' container. The retention policy is a single property per service: 'RetentionPolicy.Days'. When it is unset or zero, Azure applies no automatic deletion and the logs stay until something removes them.

Those log blobs are ordinary block blobs in the account, so they are billed exactly like any other data at the account's storage tier and redundancy. There is no separate, cheaper rate for logs. The volume is driven by request rate: a chatty account servicing millions of operations a day generates far more log data than a quiet one, which is why the cost is so uneven across an estate and why the same recommendation can be trivial on one account and material on another.

Setting a retention period to a positive number of days tells Azure to delete log data older than that window on an ongoing basis. The cleanup is handled by the platform, not by you, so once a sensible value is set the container reaches a steady state where new logs arrive and old ones age out, and the stored volume, and therefore the charge, stops climbing. Microsoft's standing guidance is to prefer Azure Storage logs in Azure Monitor over classic Storage Analytics logging, so on accounts where the logs are not actively used the cleanest answer can be to retire classic logging entirely.

What is the impact of leaving retention unset?

The direct impact is a storage charge that only ever grows. With no retention policy, every logged request adds to the '$logs' container permanently, so an account that has been logging for years can be storing a large multiple of what anyone would ever read. Because the container is hidden from the normal portal view, the cost accrues silently and is rarely reconciled against any actual use of the logs.

The second-order impact is operational noise. A '$logs' container holding years of entries is slower and more awkward to search when you genuinely need to investigate an incident, and the sheer volume can make the useful recent logs harder to find. Trimming retention to the window you actually query keeps the logs both cheaper and more useful.

There is no downside to acting that offsets the saving. You are deleting diagnostic logs, not application data, and only those older than a window you choose. The only thing to get right is sizing that window so any audit, security or troubleshooting requirement that genuinely needs older logs is still met, which for most accounts is a short period measured in days or weeks.

How do you cap classic log retention safely?

Work it in one pass: find the accounts, size the saving, set a retention period that still meets any genuine need for older logs, and decide where classic logging should simply be retired in favour of Azure Monitor.

1. Inventory classic logging across accounts

For each flagged account, check 'az storage logging show' to see which services have logging on and what the retention is. Accounts with logging on and retention at zero are the ones accruing unbounded cost. Note the size of the '$logs' container so you can prioritise by saving, not by account count.

2. Choose a retention period that meets real need

Pick a window that still satisfies any audit, security or troubleshooting requirement, then size the rest to what teams actually query, which is usually short. There is no single right answer, but most operational use of request logs falls within days to a few weeks. Document the chosen period so the choice is deliberate rather than accidental.

3. Set retention so Azure prunes for you

Apply the retention period per service. Azure then deletes log data older than the window on an ongoing basis, clearing the historical backlog and holding the container at a steady state. The change is immediate and touches only diagnostic logs, never application data.

4. Retire classic logging where it is unused

Microsoft recommends Azure Storage logs in Azure Monitor over classic Storage Analytics logging. On accounts where the classic logs are not actively used, the cleanest answer is to switch classic logging off entirely with 'az storage logging off' and, if logs are still needed, capture them through a diagnostic setting instead. For new accounts, govern blob lifecycle with a management policy so retention is set by design.

# 1. Check current classic logging settings for an account.
az storage logging show \
  --account-name logsheavyprod \
  --services bqt -o table

# 2. Cap retention: keep blob and queue request logs for 30 days, log read/write/delete.
#    Azure then deletes anything in $logs older than 30 days, on an ongoing basis.
az storage logging update \
  --account-name logsheavyprod \
  --services bq \
  --log rwd \
  --retention 30

# 3. Where classic logs are not used at all, retire classic logging entirely.
az storage logging off \
  --account-name logsheavyprod \
  --services bqt

# ----------------------------------------------------------------------------
# Declarative equivalent for new accounts. Classic logging retention is a
# data-plane property and is not set in Bicep, so govern the $logs blobs with a
# lifecycle management policy instead. This Bicep deletes blobs under the $logs
# prefix after 30 days, so retention is bounded by design rather than by drift.
# (Confirm the apiVersion against your target before deploying.)
#
# resource logRetentionPolicy 'Microsoft.Storage/storageAccounts/managementPolicies@2025-01-01' = {
#   name: 'default'
#   parent: storageAccount
#   properties: {
#     policy: {
#       rules: [
#         {
#           enabled: true
#           name: 'expire-classic-logs'
#           type: 'Lifecycle'
#           definition: {
#             filters: {
#               blobTypes: [ 'blockBlob' ]
#               prefixMatch: [ '$logs' ]
#             }
#             actions: {
#               baseBlob: {
#                 delete: { daysAfterModificationGreaterThan: 30 }
#               }
#             }
#           }
#         }
#       ]
#     }
#   }
# }

Quick quiz

Question 1 of 5

Azure Advisor flags an account under 'Revisit retention policy for classic log data in storage accounts'. What is actually accruing cost?

Keep learning

Go deeper on classic Storage Analytics logging, how retention works, and the modern Azure Monitor alternative.

You can now treat classic log retention as a clean, recurring saving: find the accounts where logging is on with no retention, size the saving by '$logs' container volume, set a retention period that still meets any genuine need, and retire classic logging in favour of Azure Monitor where the logs are unused. Azure then prunes stale logs for you and the line stops climbing.

Back to the library

Classic log retention: the savings view

A recurring storage charge you can trim to match what you actually use

This is one of the cleanest savings recommendations Azure Advisor produces. Classic log data sits in the '$logs' container and is billed at the account's ordinary blob rate. With no retention policy, that volume only ever grows, so the monthly charge climbs forever even though almost nobody reads logs more than a few weeks old. Setting a retention period caps the stored volume and converts an ever-rising line into a flat, predictable one.

The saving has two parts. The first is the recurring storage cost of all the historical logs that get deleted once a retention policy starts pruning. The second, and larger over time, is the avoided future growth: every month you keep logging on without a cap, the bill would have grown again. Both parts scale with how chatty the account is, so the highest-transaction accounts are where the saving is biggest.

It is also close to a risk-free call. You are not deleting application data, only diagnostic logs that most teams never query beyond a short window. The only judgement is choosing a retention period that still satisfies any audit or troubleshooting need, which makes this a savings the finance partner can champion without a difficult trade-off.

This lesson is for the finance partner who sees a Cost recommendation about classic log retention and wants to know how real the saving is and whether there is a catch. It covers how the charge accrues, where the saving comes from, why it keeps paying back each month, and how to size the retention period so you trim cost without throwing away logs anyone needs.

Fun fact

The container the portal will not show you

How a finance partner sizes the saving

Priya is the finance partner on the cost review. The Advisor Cost tab lists six accounts under the classic log retention recommendation. Her instinct is not to treat them as identical: the saving is proportional to how many log blobs each account is storing, which tracks how busy the account is. So she asks the team to pull, for each flagged account, the size of the '$logs' container and whether a retention policy is set. Two high-transaction production accounts turn out to hold the overwhelming majority of the log volume with retention at zero; the rest are quiet accounts where the logs are a rounding error.

That reframes the work. The saving concentrates in those two accounts: deleting years of historical request logs gives an immediate one-off storage reduction, and capping retention stops the line growing every month thereafter. The finance pack reads: 'Two accounts carry essentially all of this cost. Setting a retention period there removes the historical backlog at once and flattens future growth, with no application data touched and no service impact. The remaining four are housekeeping we will do for tidiness, not for the saving.' It is a savings recommendation she can sign off without a trade-off, because nothing of value is being thrown away.

Why this is a savings you can bank

The cost model here is unusually friendly. The charge is real and recurring, it grows on its own, and removing it carries essentially no offsetting cost or risk. Unlike most savings, there is no reserved-capacity commitment to weigh, no performance trade-off and no migration: you are simply telling Azure to stop keeping logs you do not use. The saving is the historical backlog deleted now plus all the future growth that no longer happens.

The value scales with transaction volume, so the finance discipline is to prioritise by '$logs' size rather than by the count of flagged accounts. A few busy accounts will hold almost all the addressable cost. Quote the saving as two figures where you can: the one-off reduction from clearing the backlog, and the avoided monthly growth, because the second is what makes a small-looking line worth fixing permanently rather than once.

What finance can do about the log-cost gap

Finance cannot set a retention policy, but it owns the framing that turns a list of flagged accounts into a banked, recurring saving with no offsetting cost. Three levers.

1. Prioritise by $logs size, not account count

Ask the team to report the size of the '$logs' container for each flagged account, not just the number of accounts. The saving concentrates in the busiest accounts, so a couple of high-transaction production stores will usually hold almost all of the addressable cost. Sequencing the work by container size means the biggest saving lands first.

2. Quote the saving as one-off plus avoided growth

Make explicit that the value has two parts: the one-off storage reduction from deleting the historical backlog, and the avoided future growth from capping retention so the line stops climbing every month. The second part is what justifies fixing it permanently. Presenting both stops a small-looking line being dismissed.

3. Make retention a standing review item

The saving only stays banked if new accounts do not quietly restart the accrual. Ask that classic logging retention, or a blob lifecycle policy on new accounts, becomes a line on the regular cost review so the charge cannot silently grow back. A capped, reviewed cost is worth more than a one-time cleanup.

Quick quiz

Question 1 of 5

Advisor flags six accounts under the classic log retention recommendation. As the finance partner, how should you size the saving?

Keep learning

Go deeper on classic Storage Analytics logging, how retention works, and the modern Azure Monitor alternative.

You have finished the finance view of classic log retention. You know the saving has two parts, the one-off backlog deletion and the avoided future growth, that it concentrates in the busiest accounts, and that it carries no offsetting cost or risk because only stale diagnostic logs are removed. Next time this recommendation lands, you will prioritise by '$logs' size, quote both saving figures, and make bounded retention a standing review item so the cost cannot creep back.

Back to the library

Classic log retention: the headline

A small, unmanaged cost that compounds quietly until someone caps it

This is not a large number on its own, but it is the kind of cost that compounds unnoticed. Diagnostic logs that nobody reads accumulate in storage accounts and are billed every month, forever, because no one set a rule to delete the old ones. Advisor has found the accounts where that is happening.

The decision is trivially easy to approve: set a retention period so logs older than the window you actually use are deleted automatically. There is no service impact and no application data is touched, only stale diagnostic logs. The return is an immediate one-off reduction plus the end of an open-ended growth curve.

The wider point is housekeeping discipline. A handful of these unmanaged data stores across an estate add up, and each one is a charge with no owner and no review. Capping them is the sort of low-effort, no-risk saving that signals a well-run cloud bill rather than a neglected one.

A short read for the leader who wants to know why an unmanaged log store costs money, how trivially it is fixed, and why capping these quiet, ownerless charges is a marker of a disciplined cloud bill rather than a one-off cleanup.

Fun fact

The container the portal will not show you

What it looks like when quiet costs are actually owned

During the annual cost review the CFO asked the predictable question: where is money leaking on things nobody is watching? One of the cleaner answers was classic storage logs. A few busy accounts had been logging every request for years with no rule to delete the old entries, so a storage charge had been creeping up quarter after quarter with no owner and no purpose beyond inertia.

The team's response was not a one-off cleanup but a standing rule. They set a retention period on each flagged account so Azure now prunes logs older than the window the team actually uses, deleting the historical backlog in the process, and they added the check to their cost review so a new account cannot quietly start the same accrual unnoticed. The next time the CFO asked where money was leaking on unwatched items, classic log retention was no longer on the list, because it had moved from 'nobody owns this' to 'capped by policy and reviewed.' That shift, from an open-ended charge to a flat, owned one, is the confidence signal this recommendation delivers, and it pays back every month.

Why capping this matters beyond the number

On its own this is a modest saving, and that is exactly why it is a useful signal. An unmanaged, ever-growing charge for diagnostic logs nobody reads is the kind of waste that indicates whether anyone is actually watching the bill. Catching and capping it, then making sure it cannot silently restart, is cheap evidence of a disciplined cloud operation.

The risk of inaction is not dramatic, it is dilution: a dozen of these small, ownerless charges across an estate quietly add up and erode the credibility of the cost numbers. Approving the fix costs nothing in service terms and converts an open-ended liability into a flat, predictable line, which is the trade leadership should always take.

The leadership move on quiet log costs

The executive handle is not to approve each account individually; it is to require that unmanaged log stores are capped and that the cap cannot silently come undone.

1. Approve the cap and ask for the avoided-growth figure

This is a fast yes: no service impact, no application data touched, only stale logs deleted. Ask for the saving expressed as the one-off reduction plus the avoided monthly growth, because the second figure is what turns a small line into a permanent improvement and justifies making it a standing rule.

2. Require it cannot quietly restart

A one-off cleanup that is not backstopped will reappear as soon as a new account is created with logging on and retention off. Ask that bounded retention, via a logging policy or a blob lifecycle rule on new accounts, is enforced by default so the charge cannot creep back unnoticed. Prevention by design beats periodic cleanups.

3. Treat it as a marker of bill discipline

Individually these charges are small, but whether they are caught and owned says a lot about how closely the cloud bill is watched. Use this recommendation as a prompt to ask what other unmanaged, ownerless line items exist, and make capping them a routine rather than an annual scramble.

Quick quiz

Question 1 of 5

At a cost review you are asked where money leaks on things nobody watches. Why is classic log retention a good example to cite?

Keep learning

Go deeper on classic Storage Analytics logging, how retention works, and the modern Azure Monitor alternative.

Two takeaways. Capping classic log retention is a fast, no-risk yes: no service impact, no application data touched, a one-off reduction plus the end of open-ended growth. And whether these small, ownerless charges are caught and prevented from restarting is a marker of how closely the cloud bill is watched, so make capping them a routine rather than an annual scramble.

Back to the library

Part of the learning path Cut your Azure storage bill

Trim classic Storage Analytics log retention

Classic log retention: the basics

The container the portal will not show you

Finding accounts with unbounded classic logs

How classic logging accrues costdeep dive

What is the impact of leaving retention unset?

How do you cap classic log retention safely?

1. Inventory classic logging across accounts

2. Choose a retention period that meets real need

3. Set retention so Azure prunes for you

4. Retire classic logging where it is unused

Quick quiz

Keep learning

Classic log retention: the savings view

The container the portal will not show you

How a finance partner sizes the saving

Why this is a savings you can bank

What finance can do about the log-cost gap

1. Prioritise by $logs size, not account count

2. Quote the saving as one-off plus avoided growth

3. Make retention a standing review item

Quick quiz

Keep learning

Classic log retention: the headline

The container the portal will not show you

What it looks like when quiet costs are actually owned

Why capping this matters beyond the number

The leadership move on quiet log costs

1. Approve the cap and ask for the avoided-growth figure

2. Require it cannot quietly restart

3. Treat it as a marker of bill discipline

Quick quiz

Keep learning

Related cost lessons