Related command
az monitor app-insights query
Problem
The command currently applies a one-hour --offset when the caller does not provide any time arguments:
az monitor app-insights query `
--app "<APP_INSIGHTS_NAME>" `
--resource-group "<RESOURCE_GROUP>" `
--analytics-query "requests | where timestamp >= ago(7d) | summarize RequestCount = sum(itemCount)" `
--output table
Although the KQL query explicitly asks for seven days of data, the command adds a one-hour timespan to the Application Insights query request. The service applies that timespan in addition to the time filter in the query, so the result is silently limited to one hour.
This is especially problematic for coding agents and automation. They commonly prefer Azure CLI when it is installed, trust the command result, and can make incorrect operational decisions because the CLI silently narrows the requested range.
The equivalent Log Analytics command does not add a default timespan:
az monitor log-analytics query `
--workspace "<LOG_ANALYTICS_WORKSPACE_ID>" `
--analytics-query "AppRequests | where TimeGenerated >= ago(7d) | summarize RequestCount = sum(ItemCount)" `
--output table
Proposed behavior
Align az monitor app-insights query with az monitor log-analytics query:
- With no
--start-time, --end-time, or --offset, omit timespan from the service request and let the KQL query determine the range.
- Preserve the existing behavior when
--offset is explicitly supplied.
- Preserve explicit
--start-time plus --end-time.
- If only one boundary is supplied, require
--offset rather than inventing an implicit duration.
Breaking-change impact
Existing callers that rely on the undocumented implicit one-hour range will query all available data unless they add --offset 1h. This is a default-behavior change and should be released as a major version update of the preview application-insights extension, with a clear breaking-change release note.
The explicit compatibility path is:
az monitor app-insights query ... --offset 1h
Desired timing
The goal is to publish and allow the change to bake before Microsoft Ignite, which starts on November 17, 2026.
Implementation
A draft implementation is available in the linked pull request. It:
- removes the implicit one-hour default;
- omits
timespan when no time arguments are supplied;
- retains explicit time-range behavior;
- updates command help and release history;
- bumps the preview extension to
3.0.0b1; and
- adds focused unit tests.
Related command
az monitor app-insights queryProblem
The command currently applies a one-hour
--offsetwhen the caller does not provide any time arguments:Although the KQL query explicitly asks for seven days of data, the command adds a one-hour
timespanto the Application Insights query request. The service applies that timespan in addition to the time filter in the query, so the result is silently limited to one hour.This is especially problematic for coding agents and automation. They commonly prefer Azure CLI when it is installed, trust the command result, and can make incorrect operational decisions because the CLI silently narrows the requested range.
The equivalent Log Analytics command does not add a default timespan:
Proposed behavior
Align
az monitor app-insights querywithaz monitor log-analytics query:--start-time,--end-time, or--offset, omittimespanfrom the service request and let the KQL query determine the range.--offsetis explicitly supplied.--start-timeplus--end-time.--offsetrather than inventing an implicit duration.Breaking-change impact
Existing callers that rely on the undocumented implicit one-hour range will query all available data unless they add
--offset 1h. This is a default-behavior change and should be released as a major version update of the previewapplication-insightsextension, with a clear breaking-change release note.The explicit compatibility path is:
Desired timing
The goal is to publish and allow the change to bake before Microsoft Ignite, which starts on November 17, 2026.
Implementation
A draft implementation is available in the linked pull request. It:
timespanwhen no time arguments are supplied;3.0.0b1; and