Enable Application Gateway autoscale and health probes

A gateway that cannot scale or shed a failed backend is a single point of failure in front of revenue, and the cost of getting it wrong is measured in outage minutes, not in line items. Enabling autoscale and a health probe is cheap: you pay for the capacity units the gateway actually consumes, and a higher autoscale ceiling only costs money on the days a spike actually drives it there. Running two instances rather than one is a modest, predictable increase in the gateway's hourly capacity charge, not a new product to buy.

Frame each failing recommendation as a line on the availability risk register rather than a tuning checkbox. A fixed-capacity gateway in front of a checkout flow carries a far higher expected cost of downtime than the same setting in front of an internal admin tool, yet both surface as a single Advisor finding. Map the failures to the revenue and the users behind them and prioritise by what an hour of outage would actually cost, not by the recommendation count.

The arithmetic is one-sided. The remediation is a small, bounded increase in steady-state gateway cost plus the elastic cost of capacity you only pay for under genuine load. The downside of leaving it is the documented cost of an outage: lost transactions during the window, the engineering hours burned firefighting, any SLA credits owed to your own customers, and the slower, harder-to-quantify churn that follows a public incident.

Priya is the finance partner supporting the platform team's reliability push after a near miss on the last sale day, when the checkout slowed to a crawl as traffic spiked. The Advisor report lands with seven reliability findings spread across three gateways in two subscriptions. The instinct is not to wave through a blanket capacity budget; it is to ask what is actually behind each finding. Switching a gateway to autoscale does not, by itself, raise the steady bill: you still pay for the capacity it consumes, and the higher ceiling only costs money on the days a spike genuinely drives it there. Running two instances instead of one is a modest, predictable increase in the hourly capacity charge, not a new product.

Priya asks the team to map each failing gateway to the revenue and users behind it. One gateway fronts the checkout flow and is pinned to a single fixed instance, one fronts a customer-facing portal on a fixed capacity of two, and one is an internal admin tool. The list is reframed on the availability risk register: the checkout gateway is a high cost-of-downtime item to make resilient today for a small steady-state increase plus elastic spike capacity, the portal is a scheduled change, and the admin tool is low-value drift to sweep up. The finance pack reads: 'The expensive thing here is an outage on checkout, not the gateway bill. Making the front door scale and survive a node failure costs a small, bounded amount; an hour of checkout downtime costs far more.'

The cost model here is asymmetric in a way that is easy to miss. Making a gateway resilient costs a small, bounded amount: a modest steady-state increase for running two instances, plus elastic capacity you only pay for when a spike genuinely needs it. Leaving it fragile creates an unbounded tail risk, because the cost of an outage is not the gateway bill, it is everything that stops earning while the front door is down. Each failing recommendation is a gateway where the next spike or the next node failure could take the application offline, and while the probability of any single event is low, the probability across all your gateways over time is not.

The documented cost of an outage includes the transactions lost during the window, the engineering hours burned firefighting instead of building, any SLA credits you owe your own customers, and the churn that follows a visible incident. Against that, the remediation is a small, predictable increase in steady-state gateway cost and elastic spike capacity you would want to pay for anyway. The finance role is to attach an expected cost of downtime to each fragile gateway so the work is prioritised by the revenue at risk, not by the order Advisor lists it.

Application Gateway is the front door to the application, and a front door that cannot widen under load or stay open when one hinge fails is exactly where a busy day or an unlucky restart turns into a visible outage. The report shows this as a scatter of separate reliability findings across the estate.

The leadership question is not 'is the gateway configured today?' It is 'if traffic doubles tomorrow, or one instance dies during a deployment, does the application stay up?' The defensible end state is that gateways autoscale within an agreed range, run at least two instances so they sit inside the availability SLA, and probe their backends so a failing node is taken out of rotation automatically rather than serving errors to customers.

This is a resilience decision, not a security one. The spend involved is small and largely elastic. The real question is whether the application's availability is engineered in by design, or left to depend on traffic never spiking and nothing ever failing at the wrong moment.

After the last big sale day, when the checkout slowed badly as traffic spiked and the team spent the evening firefighting a gateway that could not scale, the CEO asked the obvious question at the next review: if that happens again, do we just fall over? The honest answer at the time was that it depended on whether traffic stayed inside the capacity someone had provisioned by hand months earlier, because the front door did not scale and ran on a single instance with no real backend health check.

The team's response was to stop treating the gateway as a fixed appliance and start treating it as an elastic, self-healing front door. They switched every customer-facing gateway to autoscale within an agreed range, ensured each ran at least two instances so it sat inside the availability SLA, and configured health probes so a failing backend is pulled out of rotation automatically instead of serving errors. The next time the CEO asked the question, the answer had changed from 'we hope not' to 'the front door scales with demand, survives the loss of any single instance, and routes around a failed backend on its own.' That shift, from depending on traffic never spiking and nothing ever failing to engineering the capacity and the failover in, is the one-line confidence signal this capability delivers, and the cost of it is small next to the cost of the outage it prevents.

Nearly every avoidable availability incident at the front door comes back to the same root cause: a gateway that could not grow under load, or could not survive the loss of a single instance, in front of something customers depend on. Making gateways autoscale, run at least two instances and probe their backends is the capability that removes that root cause, and baking it into the deployment pipeline makes a fragile front door close to impossible to ship.

The cost of getting this wrong is large and lands at the worst moment, on the busy day, during the launch, while everyone is watching. The cost of getting it right is small and largely elastic. This is the rare class of change where the risk of inaction is severe and the cost of action is modest, which is exactly the trade leadership should be quickest to approve.