Log Analytics workspaces keeping Analytics data queryable for more than 90 days

What Log Analytics bills for data kept past 31 days

Retention is a separate line from ingestion. The Azure Monitor retention docs state that Analytics tables keep data for 30 days by default, that 31 days of analytics retention are included in the ingestion price, and that the analytics period can be raised to as much as 730 days at an extra cost. Data you want to keep longer but rarely read can instead sit in low-cost long-term retention, for up to 12 years, and be pulled back with search jobs.

That makes a high workspace default expensive in a quiet way. Someone raises retention to 180 or 365 days during an investigation, the incident closes, and every Analytics table that inherits the default keeps paying to hold months of logs nobody queries interactively.

Checking workspace and table retention from the CLI

List the workspaces whose default retention is above 90 days:

az monitor log-analytics workspace list \
  --query "[?retentionInDays > \`90\`].{name:name, rg:resourceGroup, days:retentionInDays}" \
  -o table

Tables can override the workspace default, so check a workspace’s tables before you change it:

az monitor log-analytics workspace table list \
  --resource-group my-rg --workspace-name my-workspace -o table

Two inputs ZopNight needs before it reports a workspace

1. The workspace’s default retention, read from Azure Resource Graph. It has to be a valid number and strictly greater than 90 days.
2. A retention charge above zero for that workspace in Azure Cost Management. ZopNight reads only the retention meters (data retention, long-term retention and archive), grouped by resource, so ingestion charges never leak into the figure.

The workspace’s total monthly cost is also read, but only as a ceiling for the saving.

Workspaces that stay out of the report

A workspace at or below 90 days is fine by this rule. So is one whose retention setting is missing or unreadable. When no retention charge is visible, either because the connection lacks Cost Management read access or because the workspace really has no billed retention, ZopNight raises no finding. It does not try to estimate retained gigabytes from ingestion volume: the ingestion metric measures data arriving, not data stored, and Azure publishes no stored-volume metric for a workspace. A guess built on that would look precise and be wrong.

How the saving is derived from the retention bill

Retention is billed only for the days beyond the 31 that ingestion already covers. Trimming to 90 days removes the part of that window that lies past day 90:

billable window  = retention days - 31
trimmed portion  = retention days - 90
monthly saving   = billed retention charges x (retention days - 90) / (retention days - 31)
                   capped at the workspace's total monthly cost

A workspace at 365 days with $200 a month in retention charges would show about $164.67: 275 of its 334 billable days go away.

Bringing retention back to 90 days

1. Ask the workspace owners which tables genuinely need a long lookback, such as sign-in or audit tables.
2. Give those tables their own retention, or keep their total retention and let the older days move to long-term retention. Microsoft documents that lowering analytics retention without changing total retention turns the difference into long-term retention rather than deleting it.
3. Lower the workspace default: az monitor log-analytics workspace update --resource-group my-rg --workspace-name my-workspace --retention-time 90.
4. Watch the retention meters in Cost Management over the next billing period.