Do not treat a polled ExpressRoute route-count alert as a deployment gate

Source facts

Microsoft warns that script or template deployments can add network prefixes faster than the custom ExpressRoute alert is triggered. The example is therefore not a guarantee that an alert will arrive before the route limit is crossed.

Collection runs in the background and can take longer than expected; the workflow recurrence must account for that to avoid queued jobs. Microsoft also says this custom workflow does not replace native ExpressRoute alerts. Microsoft Learn.

Applicability

Identify the monitored gateways, collection runbook, workflow schedule and responsible network owner. Review the actual deployment’s applicable limits separately rather than assuming one example threshold fits every gateway or route direction.

DSE recommendation

DSE recommends checking planned prefix growth before deployment and retaining the custom alert as a second observation path. Measure collection duration when selecting recurrence, and make a delayed or failed run visible to the operator. Keep threshold values consistent across the runbook and workflow, with an explicit owner for changes. Do not interpret the last successful poll as authorization for unlimited changes until the next one.

Verification

In an approved test, compare gateway observations with runbook completion and notification timestamps. Exercise a controlled threshold crossing and a deliberately delayed collection run without exceeding safe platform limits. Confirm the workflow exposes its delay and that native monitoring remains configured. Record the observed detection delay and any queueing so the deployment review uses measured evidence rather than assumed immediacy.

Official references

Microsoft Learn: Configure custom alerts to monitor advertised routes – Azure ExpressRoute. Source retrieved September 9, 2026.