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

> Route additions can outrun the custom alert workflow, and collection runtime must be considered when setting its recurrence.

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-250-do-not-treat-a-polled-expressroute-route-count-alert-as-a-deployment-gate/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:27:46+00:00
- Modified: 2026-09-10T01:20:46+00:00
- Last reviewed by DSE: 2026-09-09
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, Networks & Infrastructure
- Reading time: 2 minutes

## What you need to know

Route additions can outrun the custom alert workflow, and collection runtime must be considered when setting its recurrence.

## Potentially affected

ExpressRoute gateway route-count monitoring built with the documented Azure Automation and Logic Apps pattern.

## DSE recommendation

Use the custom alert as monitoring evidence and separately review prefix growth before approving network deployments.

## Article

## 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](https://learn.microsoft.com/en-us/azure/expressroute/how-to-custom-route-alert).

## 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](https://learn.microsoft.com/en-us/azure/expressroute/how-to-custom-route-alert). Source retrieved September 9, 2026.

## Primary reference

- Name: Configure custom alerts to monitor advertised routes - Azure ExpressRoute | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/expressroute/how-to-custom-route-alert
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Do not treat a polled ExpressRoute route-count alert as a deployment gate,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-250-do-not-treat-a-polled-expressroute-route-count-alert-as-a-deployment-gate/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.