---
title: "Logic App action: after schedule runs"
slug: "after-schedule-runs-logic-app"
updated: 2026-09-22T05:49:24Z
published: 2026-09-22T05:49:24Z
canonical: "docs.turbo360.com/after-schedule-runs-logic-app"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://docs.turbo360.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Logic App action: after schedule runs

## Overview

This article describes how to configure a Logic App that Turbo360 triggers **after** a schedule has completed its run. All resources have been started or stopped at this point. Use this hook to perform follow-up actions in external systems, such as re-enabling third-party monitoring after VMs are brought online.

### Business value

A post-schedule hook lets you restore the state of dependent systems once Turbo360 has finished acting on resources. Common uses include re-enabling monitoring alerts after VMs start, notifying operations teams that a scale-up is complete, or triggering downstream automation that depends on resources being in a known running state.

## Prerequisites

Before configuring this hook, ensure the following are in place:

- A schedule is configured in Cost Analyzer with at least one resource group.
- You have access to create and deploy a Logic App (Consumption) in Azure.
- The Logic App endpoint is accessible from Turbo360 (no firewall blocking outbound webhook calls).

### Required permissions

You must have the **Contributor** or **Owner** role on the Azure subscription to create the Logic App. Within Turbo360, you must have **Manage** access on the Cost Analyzer schedule to configure the after-schedule action.

## How it works

When a schedule is configured with an after-schedule action, Turbo360 calls the configured Logic App endpoint via HTTP after all resource operations for that schedule run have completed. The request includes HTTP headers identifying the execution context and the direction of the state change.

Your Logic App must return an HTTP 200 response. If it returns an error or times out, the schedule records the failure. Because the resource operations have already completed, the schedule outcome itself is not affected.

## Steps

Use the following steps to set up and validate an after-schedule Logic App hook. Start in **Cost Analyzer** > **Schedule Automation** and open the schedule you want to extend.

### Create the after-schedule action

Configuring the action on the schedule registers the Logic App endpoint that Turbo360 will call once the schedule run completes.

1. Open the target schedule in **Cost Analyzer** > **Schedule Automation**.
2. Navigate to the **Actions** tab.
3. Select **After schedule runs** and enter the Logic App HTTP trigger URL.
4. Save the schedule.
5. Use the **Validate** button to send a test event to the Logic App before the schedule next runs live.

### Handle the HTTP headers

The scheduler passes the following HTTP headers to your Logic App on every trigger. Use them to control your workflow logic.

| Header | Use | Values |
| --- | --- | --- |
| `Execution-Type` | Indicates whether this is a test event from the **Validate** button or a live schedule run. | `Test`: the Validate button was clicked `Actual`: the schedule ran live |
| `Schedule-Operation` | Indicates the state the schedule moved resources to. | `Start`: resources moved to the started (green) state `Stop`: resources moved to the stopped (red) state |

In your Logic App, implement the following conditional logic:

- If `Execution-Type` is **Test**, return an HTTP 200 acknowledgement and terminate. Do not perform real actions.
- If `Schedule-Operation` is **Start**, perform your post-start actions (for example, re-enable monitoring now that VMs are running).
- If `Schedule-Operation` is **Stop**, perform your post-stop actions (for example, notify a team that the scale-down is complete).

## Example scenario

A team schedules VMs to start every weekday morning. Their monitoring platform is configured to alert on VM availability. To avoid alert storms during the startup sequence, they suppressed monitoring beforehand (using a before-schedule hook) and now use an after-schedule hook to re-enable monitoring once all VMs are confirmed running. The Logic App checks for `Schedule-Operation: Start` and calls the monitoring platform's API to resume alerting.

## Logic App example

The screenshot below shows a sample Logic App workflow that handles the after-schedule extensibility scenario.

![Sample after-schedule Logic App workflow](https://cdn.document360.io/a21734f9-5f67-4835-bb81-a488f8191fa8/Images/Documentation/image-0NV3DH81.png)

## Sample Logic App template

Paste the following JSON into a Logic App Consumption workflow to get started quickly. Replace the action placeholders with your own integration logic.

```json
{
    "definition": {
        "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
        "contentVersion": "1.0.0.0",
        "triggers": {
            "When_an_HTTP_request_is_received": {
                "type": "Request",
                "kind": "Http"
            }
        },
        "actions": {
            "Response": {
                "type": "Response",
                "kind": "Http",
                "inputs": { "statusCode": 200 },
                "runAfter": { "Switch_-_Schedule_Operation": ["Succeeded"] }
            },
            "Initialize_variables": {
                "type": "InitializeVariable",
                "inputs": {
                    "variables": [
                        { "name": "executionType", "type": "string", "value": "@{triggerOutputs()?['headers']?['Execution-Type']}" },
                        { "name": "scheduleOperation", "type": "string", "value": "@{triggerOutputs()?['headers']?['Schedule-Operation']}" }
                    ]
                },
                "runAfter": {}
            },
            "Condition_-_Is_Test_Event": {
                "type": "If",
                "expression": { "and": [{ "equals": ["@variables('executionType')", "Test"] }] },
                "actions": {
                    "Response_-_Ack_-_Test": { "type": "Response", "kind": "Http", "inputs": { "statusCode": 200 } },
                    "Terminate_-_Ack": { "type": "Terminate", "inputs": { "runStatus": "Succeeded" }, "runAfter": { "Response_-_Ack_-_Test": ["Succeeded"] } }
                },
                "else": { "actions": {} },
                "runAfter": { "Initialize_variables": ["Succeeded"] }
            },
            "Switch_-_Schedule_Operation": {
                "type": "Switch",
                "expression": "@variables('scheduleOperation')",
                "default": { "actions": { "Compose_-_Do_nothing": { "type": "Compose", "inputs": "You would do nothing here because the schedule is not going to the start or stop state" } } },
                "cases": {
                    "Case_-_Start": { "actions": { "Compose_-_Do_Something_Start_State": { "type": "Compose", "inputs": "The schedule has run to move the resources to the start state. Do something here AFTER the resources are acted upon" } }, "case": "Start" },
                    "Case_-_Stop": { "actions": { "Compose_-_Do_something_Stop_State": { "type": "Compose", "inputs": "The schedule has run to the stopped state. You can do something here AFTER the schedule is actioned" } }, "case": "Stop" }
                },
                "runAfter": { "Condition_-_Is_Test_Event": ["Succeeded"] }
            }
        },
        "outputs": {},
        "parameters": { "$connections": { "type": "Object", "defaultValue": {} } }
    },
    "parameters": { "$connections": { "type": "Object", "value": {} } }
}
```

## Troubleshooting

1. **The Logic App is not triggered after the schedule completes.**  

    Cause: The after-schedule action URL may not be saved correctly, or the Logic App HTTP trigger endpoint has changed.  

    Fix: Re-open the schedule's Actions tab, verify the endpoint URL, and use the **Validate** button to confirm the trigger fires successfully.
2. **The Logic App runs but does not perform the expected post-schedule action.**  

    Cause: The Switch action may not be matching the `Schedule-Operation` value correctly.  

    Fix: Confirm the Switch expression references `@variables('scheduleOperation')` and that case values are exactly `Start` and `Stop` (case-sensitive).
3. **Test events trigger real actions in the external system.**  

    Cause: The Logic App is not checking the `Execution-Type` header before performing actions.  

    Fix: Add a condition at the start of the workflow that checks for `Execution-Type: Test` and returns HTTP 200 immediately without executing downstream actions.
4. **The Logic App receives the trigger but the `Schedule-Operation` header is empty.**  

    Cause: The header variable expression may be malformed.  

    Fix: Verify the expression `@{triggerOutputs()?['headers']?['Schedule-Operation']}` is correctly set in the Initialize variables action.
5. **Post-schedule actions run but the downstream system state is inconsistent.**  

    Cause: The after-schedule hook fires once per schedule run, but individual resources may still be transitioning when the hook is called.  

    Fix: Add a delay or polling step in the Logic App to verify the target resource state before performing downstream actions that depend on a fully stable state.

## Related articles

- [Logic App action: before schedule runs](https://docs.turbo360.com/docs/before-schedule-runs-logic-app)
- [Logic App action: before resource action](https://docs.turbo360.com/docs/before-resource-runs-logic-app)
- [Logic App action: after resource action](https://docs.turbo360.com/docs/after-resource-runs-logic-app)
- [Schedule automation example: turning off a VM](https://docs.turbo360.com/docs/simple-examples)
- [Managing optimization schedules](https://docs.turbo360.com/docs/managing-optimization-schedules)