Azure Alert not getting triggered

Hello Darshpreet Singh

Thank you for posting your query on Microsoft Q&A portal.

You can run the KQL in Logs, but the alert rule fails to validate and update with:

• “The query keeps failing because of a semantic error.”
• “Errors occurred while resolving remote entities. Access denied… The request had some invalid properties.”

Your query targets Azure Data Explorer (ADX):

 adx("https://<domain>.westus3.kusto.windows.net/AppTelemetry").ScheduledRunCompleted

These errors occur because the alert engine is validating the query against the alert rule’s scope and identity. If the rule is scoped to a Log Analytics workspace (LA) without an ADX‑capable identity, or if ADX permissions aren’t set, the alert service cannot resolve the remote ADX table, resulting in a semantic error / access denied.

Reference: https://dori-uw-1.kuma-moon.com/en-us/azure/azure-monitor/alerts/alerts-troubleshoot-log

The root cause might be due to below reasons:

1. The alert rule is not scoped to the ADX cluster (or not using an identity with access to ADX).
2. During alert validation, Azure Monitor must resolve the remote ADX entity referenced by adx(...). If the scope/permissions are wrong, validation fails with semantic errors and “invalid properties.”

Reference: https://dori-uw-1.kuma-moon.com/en-us/azure/azure-monitor/logs/cross-workspace-query

Microsoft’s cross‑service guidance clarifies that using functions like adx() in Azure Monitor has specific constraints and requires correct scope and permissions; otherwise queries can’t be validated or executed by the alert engine.

Reference: https://dori-uw-1.kuma-moon.com/en-us/azure/azure-monitor/logs/azure-monitor-data-explorer-proxy

As a resolution try below workarounds:

Option A: Create the alert against the ADX cluster (recommended when data is in ADX)

1. Scope the alert rule to your ADX cluster In the Alerts wizard, select Resource type = Azure Data Explorer cluster and set the ADX cluster as the Scope. This makes Azure Monitor run and validate the query in the correct service context.
2. Use an Azure Managed Identity with ADX permissions On the alert rule, configure Managed identity and grant it access to the ADX database/table (for example, database viewer/user as appropriate). The identity is used when the alert service executes the query against ADX.
3. Add an explicit time filter on the ADX time column When querying ADX tables from alerts, add a bounded time range (for example, last 5–60 minutes or 1 day) on the table’s timestamp column (here Timestamp). This improves validation and performance and avoids semantic issues.
4. Keep to alert query constraints Start from a table (as you do) and avoid operators that are not supported in alert validation paths; follow the guidance in Optimize log search alert queries.

Example (works when scoped to ADX cluster and identity is set):

adx("https://<domain>.westus3.kusto.windows.net/AppTelemetry").ScheduledRunCompleted
| where Status == "Failure"

Monitor your data using Azure Monitor log search alerts and the Azure Data Explorer (ADX) Database: https://techcommunity.microsoft.com/blog/azuredataexplorer/monitor-your-data-using-azure-monitor-log-search-alerts-and-the-azure-data-explo/4113837

Option B — Alert from Log Analytics (if you prefer LA‑based alerts):

If you want the alert rule to live in LA:

1. Ingest/export the ADX data into LA so the table exists in your workspace (no adx() hop).
2. Use the LA time column (TimeGenerated) in your query instead of ADX’s Timestamp.
3. Create the alert scoped to the Log Analytics workspace.

Prerequisites for log alert creation and editing (scope, permissions, condition) are covered in Create Azure Monitor log search alert rules.

Reference: https://dori-uw-1.kuma-moon.com/en-us/azure/azure-monitor/alerts/alerts-create-log-alert-rule

The prior errors happen due to below following reasons:

• Semantic error / failed to resolve table: The alert engine cannot validate or resolve the remote ADX entity when scope/identity are incorrect.
• Invalid properties / access denied: Occurs when the alert rule references a remote entity that the configured identity cannot access during save/update. Fixing scope and permissions resolves this.

If you have any other queries, please do let us know.

Thanks,

Suchitra.