Cost

Remove unused restored Log Analytics tables

A restored table puts long-term log data back into the hot cache so you can query it, and it keeps billing per gigabyte per day until you delete it. Find every restored table that is no longer being queried, confirm it is genuinely idle, and dismiss it to stop the meter.

12 min·10 sections·AZURE

Last reviewed 18 June 2026

Restored Log Analytics tables: the basics

What is a restored table, and why does it keep charging?

When you need to query log data that has aged into long-term retention, Azure Monitor lets you restore a time range of it back into the hot cache. The restore operation creates a new table whose name ends in '_RST', allocates extra compute to query it at full KQL speed, and gives you a fast view over data that would otherwise be slow or unreachable. It is a genuinely useful feature for an incident investigation or an audit lookback. The catch is that the restored table has no retention setting and never expires on its own: it keeps billing until somebody deletes it.

Azure Advisor watches for exactly this. Its cost recommendation 'Consider removing unused restored tables' (recommendation ID eb22702a-5ace-416a-abee-c03c69cede34, resource type microsoft.operationalinsights/workspaces) flags any workspace that still has restored data active when nobody appears to be using it. Microsoft describes the potential benefit as 'significant savings on data retention', because a restore is billed by the volume of data restored and by how long it stays active, in units of price per gigabyte per day.

This is the classic shape of cloud waste: a temporary thing that was never made temporary in practice. An engineer restores a few weeks of a high-volume table to chase down an incident, gets the answer, and moves on. The '_RST' table sits there, querying nothing, billing every UTC-day. The work in this lesson is to find every restored table in the estate, confirm which ones are genuinely finished, and delete them so the meter stops.

In this lesson you will learn what a restored Log Analytics table is, why it keeps billing per gigabyte per day until it is deleted, how to find every restored table across your workspaces, and how to dismiss the idle ones safely without touching the source data. You will see the exact Azure Advisor recommendation that flags this, the az CLI to list and delete restored tables, and how its per-day pricing model means a forgotten restore quietly carries the 2 TB minimum charge every day it is left active.

Fun fact

The table with no expiry date

Almost every object in Azure Monitor has a retention setting that eventually ages data out for you. A restored table is the deliberate exception: Microsoft's own documentation states it 'has no retention setting, and you must explicitly dismiss the restored data when you no longer need it'. There is a second twist. Even when the source data ages out and the restored rows are dismissed, the empty '_RST' table itself stays behind until you delete it by hand. So a workspace can quietly accumulate a small museum of empty restored tables, each one a reminder of an investigation that nobody remembered to close out.

Finding restored tables across a workspace

Priya runs the platform team at a SaaS company. Azure Advisor has raised the 'Consider removing unused restored tables' cost recommendation against the central Log Analytics workspace, and she wants to see what is actually active before deleting anything.

Restored tables all share the '_RST' suffix, so she lists the workspace tables and filters to the restored ones, then checks how long each has been sitting there.

List the tables in the workspace and keep only the restored ones, which always end in '_RST'.

$ az monitor log-analytics workspace table list \ --resource-group rg-observability \ --workspace-name law-central \ --query "[?ends_with(name, '_RST')].{name:name, state:provisioningState}" -o table

Name State

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

AppRequests_RST Succeeded

SecurityEvent_RST Succeeded

# Two restored tables still active. Confirm neither is being queried, then delete.

Every restored table ends in '_RST'. A state of 'Succeeded' means the restore completed and is live, so it is billing per gigabyte per day until it is deleted.

How a restore is billed and why deleting it is safedeep dive

A restore takes a time range from a source table in long-term retention and creates a destination table ending in '_RST' that provides a fast, full-KQL view over that data. The destination table does not copy or move the source data: Microsoft's documentation states the restored table 'provides a view of the underlying source data, but doesn't affect it in any way'. That is why deleting it is risk-free. Removing the '_RST' table dismisses the restore and stops the charge, while the source table and everything in its retention period stay exactly as they were.

The charge is the thing to understand. Restored logs are billed by the volume of data restored and by the duration the restore is active, in units of price per gigabyte per day, and the bill is applied on each UTC-day the restore stays live. Two minimums make a forgotten restore more expensive than people expect: charges are subject to a 2 TB minimum restored volume per restore, so restoring less still bills at the 2 TB floor each day, and the minimum charge is for a 12-hour restore duration. The practical upshot is that a restore is cheap to run for the hours of an investigation and quietly wasteful for the weeks it is left active afterwards.

Detection is already done for you. Azure Advisor evaluates workspaces and raises 'Consider removing unused restored tables' when restored data is active but appears unused, with a documented benefit of 'significant savings on data retention'. Because Advisor refreshes on a cycle rather than instantly, a restore you delete today clears the recommendation on the next evaluation, not the same second, which matters only if you are reconciling the saving against the dashboard.

What is the impact of leaving restored tables active?

The direct impact is recurring spend for nothing. A restored table that is no longer being queried delivers zero value and bills every UTC-day it stays active, charged on the volume restored at the per-gigabyte-per-day rate, never dropping below the 2 TB minimum. One forgotten restore of a busy table is a small charge; a habit of forgetting them across many investigations is a steady, invisible drain that shows up only when someone audits the bill.

The second-order impact is noise and drift. Empty and idle '_RST' tables clutter the workspace schema, make it harder to see which tables are real and in use, and erode trust in the cost numbers because part of the Log Analytics line is paying for data nobody is reading. Each straggler is also a small reminder that a temporary action was never closed out, which is exactly the kind of operational debt that compounds.

The reassuring side is how contained the downside of fixing it is. There is no framework requirement, no SLA and no reliability risk in play here, because a restore is purely a query convenience over data that already exists safely in retention. The only real cost of acting is a moment of confirmation that the table is genuinely idle, and the cost of not acting is paying indefinitely for compute that serves no query.

How do you clear restored tables safely?

Treat this as a short, repeatable loop rather than a one-off. The order matters: confirm a restore is genuinely idle before you delete it, so you never dismiss data an investigation is still using.

1. Inventory every restored table

List the tables in each workspace and filter to those ending in '_RST'. Treat this list, plus the Azure Advisor 'Consider removing unused restored tables' recommendation, as the source of truth. A state of 'Succeeded' means the restore is live and billing.

2. Confirm the restore is finished

For each restored table, check that no active investigation, query or workbook still depends on it. Restores are created for a specific, time-bounded purpose, so a restore older than that purpose, or one Advisor has flagged as unused, is almost always safe to remove. When in doubt, ask the owner before deleting.

3. Delete the idle ones to stop the charge

Delete each confirmed-idle '_RST' table. This dismisses the restore and stops the per-day charge immediately. It does not delete or alter the source table, so the original data stays in long-term retention exactly as it was. The charge ends on the UTC-day the restore is dismissed.

4. Make restores temporary by default

Stop the waste recurring. Adopt a convention that every restore is created for a stated, time-boxed purpose and deleted as soon as it is answered, run a scheduled sweep that lists '_RST' tables older than a threshold, and keep the Azure Advisor cost recommendation on your monthly review so any straggler is caught quickly.

# 1. Inventory: list every restored table in the workspace ('_RST' suffix).
RG=rg-observability
WS=law-central
az monitor log-analytics workspace table list \
  --resource-group "$RG" \
  --workspace-name "$WS" \
  --query "[?ends_with(name, '_RST')].name" -o tsv

# 2. Delete each confirmed-idle restored table. This dismisses the restore and
#    stops the per-GB-per-day charge. The source table is NOT affected.
for tbl in $(az monitor log-analytics workspace table list \
    --resource-group "$RG" --workspace-name "$WS" \
    --query "[?ends_with(name, '_RST')].name" -o tsv); do
  echo "Deleting idle restored table: $tbl"
  az monitor log-analytics workspace table delete \
    --resource-group "$RG" \
    --workspace-name "$WS" \
    --name "$tbl" \
    --yes
done

Quick quiz

Question 1 of 5

Azure Advisor raises 'Consider removing unused restored tables' against a workspace. What does a restored table actually cost you while it sits there?

Keep learning

Go deeper on how restored tables work, how they are billed, and how to manage Log Analytics tables from the CLI.

You can now treat restored Log Analytics tables as spend that should end when its purpose does: find every '_RST' table, confirm which are genuinely idle against the Azure Advisor recommendation, delete them to stop the per-day charge, and make restores temporary by default with a scheduled sweep. Deleting a restored table never touches the source data, so this is the rare optimisation with no trade-off to weigh.

Back to the library

Restored tables: the savings view

A recurring charge with no upside once the investigation is over

A restored table is the rare line item that is pure waste the moment it stops being queried. It was useful for the hours or days of an investigation, and after that it adds cost and nothing else. Because Azure Monitor bills a restore by the volume restored and the number of UTC-days it stays active, a restored table that is forgotten is a small daily charge that simply runs until someone notices, which can be weeks or months.

The saving is clean and immediate: delete the table and the per-day charge stops on the spot. There is no migration, no re-architecture and no trade-off to weigh, because deleting the restored table does not touch the source data, which stays exactly where it was in long-term retention. The only judgement call is confirming the restore is genuinely idle before you remove it, and Advisor surfacing the recommendation is a strong signal that it is.

Frame each flagged workspace as a recurring charge to switch off rather than a one-off cleanup. The bigger the restored volume, the bigger the daily saving, and because a restore is charged on a minimum of 2 TB even when less data was restored, even a modest restore can be carrying the floor charge every single day it is left active.

This lesson is for the finance partner who sees an Azure Advisor cost recommendation about restored tables and wants to know what the saving really is, how immediate it is, and whether there is any catch. It covers the pricing model, why the saving is risk-free, and how to turn the recommendation into a recurring sweep rather than a one-time fix.

Fun fact

The table with no expiry date

How a finance partner frames the restored-table saving

Priya is the finance partner who reviews the Azure Advisor cost tab each month. The 'Consider removing unused restored tables' recommendation appears against the central workspace, and the instinct is not to chase a headline number but to understand the shape of the charge. A restore is billed per gigabyte per day on the volume restored, with a 2 TB minimum, so two forgotten restores of a high-volume table can be carrying the 2 TB floor charge every single UTC-day with nothing to show for it.

What makes this an easy line to close is that the saving is clean. Deleting a restored table stops the daily charge immediately and does not touch the source data, so there is no risk and no migration to budget. Priya asks the team to confirm each flagged table is genuinely idle, then delete it, and reframes the recommendation on the savings tracker as a recurring charge switched off rather than a one-off cleanup. The finance note reads: 'Two idle restores removed, daily restore charge eliminated, source logs untouched, and a monthly sweep added so this does not silently accrue again.'

The financial impact of leaving restored tables active

The impact in money terms is a recurring charge for nothing. A restored table that is no longer being queried bills on every UTC-day it stays active, charged on the volume restored at the per-gigabyte-per-day rate and never dropping below the 2 TB minimum, so even a modest restore carries the 2 TB floor each day it is left. One forgotten restore is a small daily charge; a habit of forgetting them across many investigations is a steady, avoidable line that only surfaces when someone audits the bill.

The saving is unusually clean to bank. Deleting an idle restored table stops the per-day charge immediately and removes no capability, and because it does not touch the source data in long-term retention there is no migration to budget and no trade-off to weigh. The only check is confirming the restore is genuinely idle, which the Advisor flag already strongly suggests, so each flagged workspace is best framed as a recurring charge to switch off rather than a one-off cleanup.

What finance can do about restored-table waste

Finance cannot delete a table, but it owns the framing that turns a recurring Advisor finding into a switched-off charge and a habit that stops it recurring. Three levers.

1. Treat each restore as a recurring charge, not a one-off

Make explicit that a restored table bills per gigabyte per day on every UTC-day it stays active, with a 2 TB minimum, so a forgotten restore is not a sunk one-time cost but a meter that runs until someone stops it. Quantify the saving as a per-day charge eliminated, which makes the value of acting promptly obvious and turns the Advisor recommendation into a tracked line on the savings register.

2. Bank the saving as risk-free

Deleting a restored table does not touch the source data and removes no capability, so there is no trade-off to weigh and no downside to budget against. Record these as risk-free savings on the optimisation tracker so they are not held up behind the same review as changes that carry a genuine trade-off. The only check needed is confirming the restore is idle, which the Advisor flag already strongly suggests.

3. Make the sweep recurring so it does not come back

A one-time cleanup saves money once; a monthly review of the 'Consider removing unused restored tables' recommendation and a scheduled '_RST' sweep keep it saved. Ask for the restored-table count and age to appear on the cost review so a new straggler is caught in weeks, not discovered in an annual audit after it has billed for months.

Quick quiz

Question 1 of 5

As the finance partner, how should you characterise the saving from deleting an idle restored table?

Keep learning

Go deeper on how restored tables work, how they are billed, and how to manage Log Analytics tables from the CLI.

You have finished the finance view of restored tables. You know the charge is per gigabyte per day on every UTC-day a restore stays active, with a 2 TB floor, so a forgotten restore is a running meter rather than a sunk cost. The saving is immediate and risk-free because deletion does not touch the source data. Next time the Advisor recommendation appears, you will bank it as a recurring charge switched off and add a monthly sweep so it does not silently accrue again.

Back to the library

Restored tables: the headline

Money leaving the account for a query nobody is running any more

A restored Log Analytics table is spend with a clear start and no automatic stop. Someone needed to look at old log data, restored it, got the answer, and the charge kept running because nothing deletes a restore for you. Multiply that by every investigation across the year and it becomes a steady drip of cost for compute nobody is using.

The leadership question is simple: is anyone watching for spend that has outlived its purpose? Azure Advisor already flags these as a cost recommendation, so the only thing standing between the finding and the saving is a habit of acting on it. This is a no-trade-off decision: deleting an idle restore saves money and changes nothing about the underlying data.

This is the easiest class of saving to approve. There is no risk to the source logs, no service to migrate and no capability lost. The defensible end state is that no restored table is left active once the work that needed it is done, and that the estate is swept for stragglers on a schedule rather than by luck.

A short read for the leader who wants to know what a restored table is, why it costs money after its job is done, and why switching it off is the rare saving with no downside. It frames the end state: no investigation leaves a meter running, and the estate is swept on a schedule.

Fun fact

The table with no expiry date

What it looks like when no investigation leaves a meter running

After a cost review surfaced a line for restored log data that nobody on the leadership team recognised, the question at the next meeting was straightforward: what is this, and why are we still paying for it? The honest answer was that an engineer had restored old logs to investigate an incident months earlier, solved the problem, and never deleted the restore, so it had been billing quietly ever since.

The team's response was to stop treating restores as fire-and-forget. They listed every '_RST' table across the estate, deleted the ones that were finished, and added a scheduled sweep that flags any restored table older than a set threshold against the Azure Advisor recommendation. The next time the cost review ran, there was no mystery restore line, because the platform now closes out restores rather than relying on whoever opened them remembering to. That shift, from spend that outlives its purpose to spend that ends when the work does, is the confidence signal this saving delivers, and it costs nothing but the discipline to act on a recommendation Azure already raises.

Why leaving restored tables active matters to the business

The impact that reaches leadership is spend that has outlived its purpose. An investigation needed old log data, restored it, got the answer, and the charge kept running because nothing deletes a restore for you. Across a year of investigations that becomes a steady drip of cost for compute nobody is using, and it erodes confidence in the cost numbers when part of the Log Analytics line is paying for data no one is reading.

The reassuring side is that fixing it carries no downside. There is no framework requirement, no SLA and no reliability risk in play, because a restore is purely a query convenience over data that already sits safely in retention. Deleting an idle restore saves real money and changes nothing about the underlying logs, so the defensible end state is simple: no investigation leaves a meter running, and the estate is swept on a schedule against the Advisor recommendation rather than by luck.

The leadership move on restored tables

The executive handle is not to approve each deletion; it is to require that spend ends when its purpose does, and that the estate is swept on a schedule rather than by luck.

1. Approve the risk-free saving without ceremony

This is the clearest possible optimisation: it saves money, touches no source data, and removes no capability. Make it explicit that deleting idle restored tables does not need the same scrutiny as a change with a trade-off, so the saving is banked quickly rather than queued behind heavier reviews.

2. Require that restores are temporary by design

Ask for a convention that every restore is created for a stated, time-boxed purpose and closed out as soon as it is answered. The goal is that no investigation leaves a meter running, so the cost of using the feature is the hours it was needed, not the months it was forgotten.

3. Put the Advisor recommendation on the recurring review

Azure already raises 'Consider removing unused restored tables' as a cost recommendation. The leadership requirement is simply that someone owns acting on it on a cadence, backed by a scheduled sweep for '_RST' tables, so stragglers are caught in the normal rhythm of operations rather than in a once-a-year cost audit.

Quick quiz

Question 1 of 5

A cost review surfaces a restored-log-data charge nobody recognises. What is the defensible end state you should ask for?

Keep learning

Go deeper on how restored tables work, how they are billed, and how to manage Log Analytics tables from the CLI.

Two takeaways. Restored tables are the clearest kind of saving: deleting an idle one stops real spend, touches no source data and removes no capability, so it is the trade you should approve fastest. And the defensible end state is that no investigation leaves a meter running, with restores made temporary by design and the Azure Advisor recommendation owned on a recurring cadence rather than discovered in an annual audit.

Back to the library

Part of the learning path Kill idle Azure waste

Remove unused restored Log Analytics tables

Restored Log Analytics tables: the basics

The table with no expiry date

Finding restored tables across a workspace

How a restore is billed and why deleting it is safedeep dive

What is the impact of leaving restored tables active?

How do you clear restored tables safely?

1. Inventory every restored table

2. Confirm the restore is finished

3. Delete the idle ones to stop the charge

4. Make restores temporary by default

Quick quiz

Keep learning

Restored tables: the savings view

The table with no expiry date

How a finance partner frames the restored-table saving

The financial impact of leaving restored tables active

What finance can do about restored-table waste

1. Treat each restore as a recurring charge, not a one-off

2. Bank the saving as risk-free

3. Make the sweep recurring so it does not come back

Quick quiz

Keep learning

Restored tables: the headline

The table with no expiry date

What it looks like when no investigation leaves a meter running

Why leaving restored tables active matters to the business

The leadership move on restored tables

1. Approve the risk-free saving without ceremony

2. Require that restores are temporary by design

3. Put the Advisor recommendation on the recurring review

Quick quiz

Keep learning

Related cost lessons