Access issue for ADX cluster alert

Ian Joynson-Crosby 0 Reputation points
2026-04-08T11:18:06.6133333+00:00

Good day, I have a set of "Log search alert rules" which run successfully right now. Currently the cluster has "Enabled from all networks" selected under Networking.

I am now tightening up security of the cluster and now have "Enabled from selected IP addresses" selected. I have added the IP addresses I want and included in that list are the service tag ip's. I have also selected the following service tags from the drop down: AzureMonitor, KustoAnalytics, AzureResourceManager, ActionGroup (amongst others to try and fix the issue I am seeing). But essentially, now with the restrictions in place, I am getting a gateway timeout (429) code. If I switch back to "Enabled from all networks" the queries work once more. It's a right head scratcher.

I have been on this issue for a couple of days now and I am getting the feeling I may have to revert back to public access but thought to check here in case there is someone who has come across this issue in the past and managed to solve.

A crude shortened example for one of the alerts is as follows (obviously specific connection details have been amended):

adx('https://clustername.region.kusto.windows.net/DBNAME').TableName
| where Timestamp > ago(1d)
Azure Data Explorer
Azure Data Explorer

An Azure data analytics service for real-time analysis on large volumes of data streaming from sources including applications, websites, and internet of things devices.

2 answers

Sort by: Oldest
Most helpful Newest Oldest
  1. Pilladi Padma Sai Manisha 11,715 Reputation points Microsoft External Staff Moderator
    2026-04-08T12:07:01.0666667+00:00

    Hi Ian Joynson-Crosby,
    Thankyou for reaching out microsoft Q&A!
    For your scenario, the most reliable way to make alert rules work with restricted network access is to move away from IP-based allow lists and use Private connectivity.

    I’d recommend configuring a Private Endpoint (Private Link) for your ADX cluster and ensuring Azure Monitor can resolve and reach the cluster via private DNS. This setup avoids dependency on changing outbound IP ranges and keeps your alerts working consistently while maintaining a locked-down posture.

    If Private Link isn’t an option right now, the practical alternative is to keep public access enabled and secure the cluster using Azure AD (RBAC) and database-level permissions, rather than relying on IP restrictions.

    You can review the official guidance here:

    https://learn.microsoft.com/azure/data-explorer/security-network-private-endpoint

    https://learn.microsoft.com/azure/azure-monitor/alerts/alerts-log

    This approach tends to be the most stable for alerting scenarios.

    Was this answer helpful?

    0 comments
  2. Ian Joynson-Crosby 0 Reputation points
    2026-08-19T16:09:49.03+00:00

    This was resolved some time ago. I had to recreate some infra and it worked.

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.