Build a Nightly Azure VM Auto-Shutdown That Emails You When It’s Done — Part 2: The Logic App

This is where Logic Apps genuinely beat a script, and most people never use it.

Designer. Wrap the Resource Graph query, the For each loop, and the send-email action in a Scope named Shutdown_Sequence. Then add a second action after the scope — another email, subject [FAILED] Nightly VM Shutdown — open its three-dot menu → Configure run after, uncheck is successful, and check has failed and has timed out.

You now have a real error path. Success sends the summary; any failure anywhere in the scope sends an alert instead. No try/catch, no $ErrorActionPreference, and it’s visible to anyone who opens the designer.

Add a retry policy while you’re there: on the deallocate HTTP action, Settings → Retry Policy → Exponential, count 4, interval PT10S. ARM throttles under load and a bare retry turns most 429s into non-events.

Deploy from the command line. Here’s the whole workflow as a definition file — trigger, query, loop, scope, and both success and failure paths. Save it as vm-shutdown-workflow.json:

{
  "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
  "contentVersion": "1.0.0.0",
  "triggers": {
    "Recurrence": {
      "type": "Recurrence",
      "recurrence": {
        "frequency": "Day",
        "interval": 1,
        "schedule": { "hours": [ 0 ], "minutes": [ 0 ] },
        "startTime": "2026-08-11T00:00:00",
        "timeZone": "Eastern Standard Time"
      }
    }
  },
  "actions": {
    "Get_Tagged_VMs": {
      "type": "Http",
      "inputs": {
        "method": "POST",
        "uri": "https://management.azure.com/subscriptions/00000000-0000-0000-0000-000000000000/providers/Microsoft.ResourceGraph/resources?api-version=2022-10-01",
        "body": {
          "query": "Resources | where type =~ 'microsoft.compute/virtualmachines' | where tags['AutoShutdown'] =~ 'True' | project id, name"
        },
        "authentication": {
          "type": "ManagedServiceIdentity",
          "audience": "https://management.azure.com/"
        }
      }
    },
    "For_each": {
      "type": "Foreach",
      "runAfter": { "Get_Tagged_VMs": [ "Succeeded" ] },
      "foreach": "@body('Get_Tagged_VMs')?['data']",
      "runtimeConfiguration": {
        "concurrency": { "repetitions": 5 }
      },
      "actions": {
        "Deallocate_VM": {
          "type": "Http",
          "inputs": {
            "method": "POST",
            "uri": "https://management.azure.com@{items('For_each')?['id']}/deallocate?api-version=2024-11-01",
            "authentication": {
              "type": "ManagedServiceIdentity",
              "audience": "https://management.azure.com/"
            },
            "retryPolicy": {
              "type": "exponential",
              "count": 4,
              "interval": "PT10S"
            }
          }
        }
      }
    }
  },
  "outputs": {}
}

Then deploy it:

az logic workflow update \
  --resource-group acs-eng-test-eastus-rg \
  --name la-vm-shutdown-eng-test-eastus \
  --definition vm-shutdown-workflow.json

Or with PowerShell:

Set-AzLogicApp -ResourceGroupName 'acs-eng-test-eastus-rg' `
    -Name 'la-vm-shutdown-eng-test-eastus' `
    -DefinitionFilePath '.\vm-shutdown-workflow.json' -Force

Add your notification action to the actions block before deploying — either an ACS HTTP call or, if you’ve already consented to the Office 365 connector in the designer, the connector reference the portal generated for you.

Step 8 — Test, Verify, and Get It Into Source Control

Designer. Hit Run Trigger → Run. Don’t wait for midnight.

The run history is the best part of this whole approach. Open the run and every action shows its inputs, outputs, duration, and status. Click the failed one and you see the exact ARM response body. Compared to reading a runbook’s job stream, it’s a different sport.

Command line.

az logic workflow show \
  --resource-group acs-eng-test-eastus-rg \
  --name la-vm-shutdown-eng-test-eastus \
  --query "{state:state, trigger:definition.triggers.Recurrence.recurrence}"

Check four things either way:

• Get_Tagged_VMs returned the VMs you expected — and only those.
• Each loop iteration returned 200 or 202.
• The portal shows the VMs as Stopped (deallocated), not just Stopped.
• The email arrived with a real timestamp.

Then export the definition. Even if you built this entirely by clicking, don’t leave it living only in the portal. Designer toolbar → Code view → copy the JSON into a file in Git. Or pull it down:

az logic workflow show \
  --resource-group acs-eng-test-eastus-rg \
  --name la-vm-shutdown-eng-test-eastus \
  --query definition > vm-shutdown-workflow.json

A Logic App with no exported definition is a single-point-of-failure that a mis-click can destroy. Thirty seconds now.

When It Doesn’t Work

The failures here look different from the runbook’s.

Get_Tagged_VMs returns an empty data array. Almost always the missing Reader assignment at subscription scope from Step 2. It fails silently with a 200, which is what makes it confusing.

403 Forbidden on the deallocate action. RBAC hasn’t propagated, or the role is scoped to a resource group that doesn’t contain the VM. Resource Graph happily returns VMs your shutdown role can’t touch. Scope the query to match your permissions, or widen the permissions deliberately.

The workflow ran at 8:00 PM. Trailing Z on startTime. Strip it.

429 Too Many Requests inside the loop. Concurrency is too high. Drop the degree of parallelism and confirm the exponential retry policy is in place.

The trigger never fired at all. Check the workflow is Enabled — a saved workflow is not necessarily a running one — and that you gave it a full 24 hours of lead time before the first scheduled run.

Email action fails with an expired connection. The Office 365 connector’s OAuth grant was tied to an account that changed password or left. This is the failure mode that makes the ACS-over-HTTP alternative worth the extra setup.

Runbook or Logic App? An Honest Comparison

Having built both, here’s where each actually wins.

Pick the Logic App when the people maintaining it aren’t scripters, when you want run history and per-action error visibility without instrumenting anything, when you need to fan out to Teams or ServiceNow or an approval step later, or when your organization’s change process treats low-code as lower risk. The visual error path in Step 7 is genuinely better than what most people write in PowerShell.

Pick the runbook when the logic is complex or conditional, when you want it in Git with pull requests and readable diffs, when you need -WhatIf style dry runs, or when the same logic needs to run somewhere else too. A JSON workflow definition technically diffs, but nobody enjoys reviewing it.

Cost is a wash at this scale — both are effectively free for a nightly job. At high volume, Consumption Logic Apps bill per action execution, so a loop over 500 VMs adds up in a way a runbook doesn’t.

Source control is the sharpest difference, and it cuts against the Logic App. A runbook is a .ps1 — it diffs cleanly, reviews cleanly, and a colleague can comment on line 47. A workflow definition is nested JSON where reordering two actions produces a diff nobody can read. You can absolutely keep it in Git, and you should, but don’t pretend the review experience is equivalent.

Testing cuts the other way. The runbook’s WhatIfOnly parameter is a dry run you had to build yourself. The Logic App’s run history is a dry run you get for free, retroactively, on every execution — including the ones that already failed at 3 AM last Tuesday. Resubmitting a failed run from history with one click has no runbook equivalent.

The honest tiebreaker is the 2 AM question: when this breaks, who fixes it? Build the version that person can read. That’s not a technical criterion, and it’s usually the right one.

If you’re genuinely split, here’s the tie-break I’d use: build the Logic App if this automation is likely to grow — approvals, Teams notifications, ticket creation, conditional logic per environment. Composition is what Logic Apps are for, and each addition is a drag-and-drop rather than a rewrite. Build the runbook if this is likely to stay exactly what it is today, because a stable script is close to zero-maintenance and the portal’s designer will keep changing around you.

Wrapping the Series

Two implementations, one outcome: VMs that stop themselves every night, an email that tells the truth about when it happened, and not a single stored credential anywhere.

Whichever you built, do the two things people skip. Alert on absence of a successful run, not just on failure — a disabled schedule is silent, and silence is indistinguishable from an inbox you haven’t checked. And keep every timestamp generated rather than typed, so the next schedule change doesn’t quietly turn your notification into misinformation.

Now go find the VMs nobody’s turning off.