Azure rebooted the server. The bank never noticed.

Understand it one step at a time

The short runs these in order in about 57 seconds. Here they are written out — pick any step to jump the short straight to it.

1. 1

   9,400 customers. One payments app

   A retail banking app on Azure. Transfers are clearing, nobody is thinking about servers.

   msdevbank.com · online

2. 2

   Two VMs behind one load balancer

   VM1 and VM2 sit in the same availability set. Every request is split between them.

   load balancer · VM1 50% · VM2 50%

3. 3

   Azure schedules host maintenance

   Not a crash. A planned platform update — the physical host under your VM needs patching and a reboot.

   notice · planned maintenance window

4. 4

   VM1 starts installing updates

   Azure takes the first update domain offline. VM1 stops answering and begins the host patch.

   UD 0 · VM1 updating

5. 5

   Everyone expects the app to drop

   Half the capacity is mid-reboot at peak hour. This is the moment the error page usually shows up.

   expected: HTTP 503

6. 6

   The load balancer already moved

   The health probe on VM1 stops answering, so Azure Load Balancer drops it from the backend pool.

   probe failed · VM1 removed

7. 7

   VM2 takes 100% of the traffic

   Same URL, same session, same balance on screen. The surviving VM simply absorbs the load.

   failover complete · VM2 100%

8. 8

   VM1 reboots and comes back

   The host restarts, the VM boots, the probe answers again — and the load balancer puts VM1 straight back in.

   UD 0 · VM1 back in rotation

9. 9

   Only now does Azure touch VM2

   Azure waits for the first update domain to recover — up to 30 minutes — before starting the next one.

   UD 1 · VM2 updating

10. 10

    VM1 serves while VM2 patches

    The roles swap cleanly. The freshly patched VM carries every request while the other one reboots.

    VM1 100% · VM2 updating

11. 11

    Both VMs patched. Nobody noticed

    Two host reboots inside one maintenance window, and the payments counter never dropped to zero.

    maintenance complete · 0 downtime

12. 12

    Azure Update Domain

    That sequence has a name. An update domain is a group of VMs Azure reboots together during planned maintenance.

    the term · update domain

13. 13

    One update domain at a time

    Five by default, up to twenty. Azure walks them in order and waits about 30 minutes after each one.

    UD 0 → UD 1 → UD 2 → UD 3 → UD 4

14. 14

    Update domain vs fault domain

    Update domains cover the maintenance Azure schedules. Fault domains cover the hardware failure nobody schedules.

    planned vs unplanned

15. 15

    Update Domain = Planned Maintenance Without Downtime

    Spread across update domains, a platform reboot becomes a rolling restart instead of an outage.

    SLA 99.95% · availability set

16. 16

    Follow for Azure & Cloud Engineering Tips

    One architecture idea per reel, from the failure backwards. Save this one for your next design review.

    MSDevBuild · Azure & Cloud Engineering