Azure Logic App Workflow Failure Rate Sentinel

A Logic App that is triggered on a schedule or by an external event can start failing every single run with nobody watching, especially for workflows that do not have a human checking the run history regularly. This blueprint lists recent runs filtered server-side to Failed status and alerts Slack with the count the moment any exist.

How it works

1. periodic_failure_check (io.kestra.plugin.core.trigger.Schedule) runs every 30 minutes, explicitly passing azure_subscription_id, resource_group_name, workflow_name, and max_runs_to_check through its own inputs: block so the flow is self-contained when the trigger fires. Shipped disabled so a manual run can be verified first.
2. probe_failed_runs (io.kestra.plugin.azure.logicapps.ListRuns) lists up to max_runs_to_check runs filtered server-side to statusFilter: "Failed", returning total.
3. evaluate_failed_runs (io.kestra.plugin.core.flow.If) branches on whether total > 0.
   • then (FAILURES_DETECTED): alert_failed_runs reports the failed run count to Slack.
   • else (HEALTHY): log_workflow_healthy records a clean check.
4. log_audit_complete always runs last, printing the failed run count regardless of which branch fired.
5. The errors block alerts Slack separately if the flow itself fails outright - an unreachable Azure API or bad credentials must not read as HEALTHY.

What you get

• A HEALTHY/FAILURES_DETECTED answer computed by Azure's own Logic Apps management API filter, not by paging through every run and filtering client-side.
• A bounded query (maxRuns) so a workflow with a long failure history cannot turn a routine health check into an unbounded API call.
• A worked example of io.kestra.plugin.azure.logicapps.ListRuns's statusFilter property, used exactly as the plugin's own documentation example shows it, wired into a real alerting flow instead of a bare log statement.

Who it's for

• Integration and automation teams running Azure Logic Apps who need an early signal when a workflow starts failing between the times someone happens to check its run history.
• On-call engineers who want one Slack alert with the exact failed run count instead of opening the Azure portal to check manually.
• Anyone evaluating the Azure Logic Apps plugin who wants a worked example of ListRuns driving a real governance decision, not just a log statement.

Why orchestrate this with Kestra

Logic Apps itself has no cross-workflow alerting primitive for "this workflow has started failing" beyond what you wire up per-workflow inside Azure Monitor - and that is a separate configuration surface from the flow that actually needs to react. Kestra supplies the schedule, the HEALTHY/FAILURES_DETECTED classification as a first-class branch, and an execution history that shows exactly when a workflow started failing and how many runs were affected.

Prerequisites

• An Azure subscription with a deployed Logic App workflow that has run at least once (update azure_subscription_id, resource_group_name, workflow_name).
• An Azure AD service principal (tenantId, clientId, clientSecret) with Microsoft.Logic/workflows/runs/read permission (the built-in Logic App Contributor or Reader role covers this).
• A Slack incoming webhook for alerts.

This blueprint has no local, account-free testing path. io.kestra.plugin.azure.logicapps.ListRuns calls Azure's Resource Manager (control-plane) API with AzureEnvironment.AZURE hardcoded in the plugin's own source - unlike Azure Storage, which Azurite emulates at the data-plane level, there is no official local emulator for Logic Apps workflow-run management calls. A real Azure subscription is required, the same baseline prerequisite every other Azure/AWS/GCP-targeting blueprint in this repository assumes.

Secrets

• AZURE_TENANT_ID / AZURE_CLIENT_ID / AZURE_CLIENT_SECRET: service principal credentials used by io.kestra.plugin.azure.logicapps.ListRuns.
• SLACK_WEBHOOK_URL: Slack incoming webhook used by alert_failed_runs and the errors block.
• In Kestra OSS (no Enterprise secrets backend), secrets are supplied as environment variables prefixed SECRET_, base64-encoded - for example SECRET_AZURE_CLIENT_SECRET=$(echo -n '<your-client-secret>' | base64) - and read back in flows with {{ secret('NAME') }}.

Inputs

Input	Type	Default	Allowed values
azure_subscription_id	STRING	<your-azure-subscription-id>	Valid Azure subscription GUID
resource_group_name	STRING	my-resource-group	Resource group containing the Logic App
workflow_name	STRING	my-logic-app	Target Logic App workflow name
max_runs_to_check	INT	50	Any positive integer

Outputs

• {{ outputs.probe_failed_runs.total }}: number of runs matching statusFilter: "Failed" this check.
• {{ outputs.probe_failed_runs.runs }}: list of matching run records (id, name, status, code, startTime, endTime, correlationId, error, outputs).

Quick start

1. Deploy a Logic App workflow in a real Azure subscription and let it run at least once successfully.
2. Add the AZURE_TENANT_ID, AZURE_CLIENT_ID, AZURE_CLIENT_SECRET, and SLACK_WEBHOOK_URL secrets.
3. Run the flow manually against a healthy workflow and confirm log_workflow_healthy fires.
4. Force a run to fail (for example, by pointing one of the workflow's own actions at an invalid endpoint) and re-run this flow to confirm alert_failed_runs fires with a count of at least 1.
5. Enable periodic_failure_check once you trust the check against your real workflow.

How to extend

• Loop over several workflow_name values with io.kestra.plugin.core.flow.Loop to audit every critical Logic App in a resource group in one run.
• Surface individual runs[].error payloads in the Slack message (rather than only the count) once the alert volume is low enough for that level of detail to be useful in-channel.
• Add a second probe using io.kestra.plugin.azure.logicapps.Run to automatically re-trigger the workflow from its last good input once a human has reviewed and approved the failure.

Pitfalls

• This blueprint has no local emulator-based testing path at all. ListRuns hits Azure's control-plane Resource Manager API, which (unlike Azure Storage's data-plane APIs, which Azurite emulates) has no official local emulator - a real Azure subscription is required even for a first manual test run.
• statusFilter accepts only the exact status strings Azure's own WorkflowStatus enum recognizes (for example Failed, Succeeded, Cancelled) - verified from ListRuns's own source, which maps the input string through that enum before building the server-side filter; an unrecognized value fails before the API call is made.
• maxRuns caps how many failed runs this blueprint sees, not the true failure count. If the real number of failed runs exceeds max_runs_to_check, total reports the capped value, not the actual total.
• This blueprint is UNTESTED against a live Azure subscription. The ListRuns and RunRecord properties and output fields are taken verbatim from the plugin's own source on main - but no Kestra engine was run to execute this flow end to end.

Links

• Kestra Azure plugin documentation
• Azure Logic Apps workflow run history documentation
• Kestra secrets (OSS vs Enterprise)