Script icon
Docker icon
If icon
SlackIncomingWebhook icon
Log icon
Return icon
Schedule icon

Azure AppService Plan Memory Leak and Restart Sentinel

Audits Azure App Service Plans via Azure Monitor to detect memory saturation and container restart loops, alerting SRE teams via Slack.

Categories
CloudInfrastructure

Enterprise web portals, API gateways, and microservices hosted on Microsoft Azure depend on Azure App Service Plans to provide managed compute instances (server farms) that execute containerized applications and native runtimes (.NET, Java, Node.js, Python). When application code develops gradual memory leaks, unclosed database connection objects accumulate, or high-throughput file upload buffering exhausts system RAM, the underlying App Service worker instance approaches 100% memory utilization. In response, Azure App Service container orchestrators forcibly recycle worker processes, causing dropped in-flight HTTP requests, session disconnections, and cold-start latency surges. This sentinel interrogates the Azure Monitor Metrics API on a 10-minute cadence, inspects MemoryPercentage and CpuPercentage across worker instances, flags plans exceeding 85% memory consumption, and delivers actionable incident runbooks to SRE teams on Slack before out-of-memory recycling crashes production apps.

How it works

  1. Scheduled triggering: Executes every 10 minutes via automated cron trigger (*/10 * * * *) or runs on-demand via manual execution.
  2. Metric query construction: Targets the Azure Resource Manager resource URI for the specific App Service Plan (Microsoft.Web/serverfarms).
  3. Telemetry evaluation: Fetches MemoryPercentage and CpuPercentage metrics across a 15-minute rolling lookback window.
  4. Threshold comparison: Verifies whether maximum recorded memory utilization meets or exceeds max_memory_percent_threshold.
  5. Conditional alerting: An io.kestra.plugin.core.flow.If flowable checks if memory is saturated and dispatches an alert card to #azure-compute-alerts.
  6. Manifest export: Emits a structured JSON audit payload detailing memory percentages, CPU averages, and tier scaling advice.

Architecture diagram

flowchart TD
  A[ten_minute_appservice_audit Schedule Trigger] --> B[scan_appservice_memory Python Script]
  B --> C[check_memory_saturation Flowable If]
  C -- Memory Saturated --> D[notify_slack_memory_saturation Webhook]
  C -- Compute Nominal --> E[log_compute_health_state Log]
  D --> E
  E --> F[export_appservice_manifest Return]

What you get

  • Proactive detection of gradual application memory leaks before automated worker recycling drops connections.
  • Visibility into true physical server farm memory saturation across all co-hosted web applications.
  • Actionable Slack notifications containing current memory metrics and vertical/horizontal scaling runbooks.
  • Structured JSON execution manifests supporting capacity planning and auto-scale rule tuning.

Who it's for

  • Cloud Infrastructure Engineers operating multi-tenant Azure App Service Plans.
  • Site Reliability Engineers troubleshooting intermittent 502/503 HTTP errors and process recycles.
  • Full-Stack Developers profiling application heap growth and Garbage Collection behavior.

Why orchestrate this with Kestra

While Azure Monitor captures basic metric trends, integrating memory exhaustion alerts into cross-platform incident response channels requires workflow automation. Kestra connects directly to Azure APIs, evaluates custom operational thresholds, formats rich diagnostic cards with scaling guidance, and can trigger automated scale-out workflows. With Kestra's containerized Python runner and native secret management, teams maintain robust cloud compute guardrails without deploying third-party agent daemons.

Use cases

  • Gradual Memory Leak Early Warning: Catch memory bloat in Node.js or Java containers over hours before out-of-memory crashes occur.
  • Multi-App Server Farm Overcrowding: Detect when co-hosting too many web applications on a single App Service Plan exhausts available RAM.
  • Scale-Out Rule Verification: Ensure that Azure autoscale rules trigger appropriately before memory reaches dangerous recycling ceilings.

Inputs

Name Type Default Description
azure_subscription_id STRING 12345678-1234-1234-1234-123456789abc Azure subscription identifier containing the App Service Plan.
resource_group_name STRING rg-production-apps Name of the Azure Resource Group hosting the App Service Plan.
app_service_plan_name STRING asp-ecommerce-prod Name of the target Azure App Service Plan to audit for memory saturation.
max_memory_percent_threshold FLOAT 85.0 Maximum acceptable memory utilization percentage before triggering exhaustion alerts.
alert_on_saturation BOOL true Whether to dispatch automated Slack alerts when App Service Plan memory is saturated.

Expected outputs

  • {{ outputs.scan_appservice_memory.vars.plan_name }}: Name of the evaluated App Service Plan.
  • {{ outputs.scan_appservice_memory.vars.max_memory_percent }}: Maximum recorded memory utilization percentage.
  • {{ outputs.scan_appservice_memory.vars.is_saturated }}: Boolean flag indicating whether memory utilization breached safety limits.
  • {{ outputs.export_appservice_manifest.value }}: Structured dictionary containing the consolidated App Service diagnostic manifest.

Prerequisites

  • Outbound HTTPS network access from Kestra execution workers to Azure Resource Manager endpoints (management.azure.com).
  • An Azure Service Principal configured with Monitoring Reader permissions on the target resource group.
  • A Slack Incoming Webhook URL configured in Kestra secrets.

Secrets

  • AZURE_CLIENT_ID: Service Principal Application (Client) ID.
  • AZURE_CLIENT_SECRET: Service Principal Secret.
  • AZURE_TENANT_ID: Azure Active Directory Directory (Tenant) ID.
  • SLACK_WEBHOOK_URL: Slack Incoming Webhook URL used to dispatch compute alerts.

Quick start

  1. Register AZURE_CLIENT_ID, AZURE_CLIENT_SECRET, AZURE_TENANT_ID, and SLACK_WEBHOOK_URL in your Kestra secret storage.
  2. Import this blueprint into your Kestra instance under the company.cloud namespace.
  3. Update azure_subscription_id, resource_group_name, and app_service_plan_name with your App Service Plan details.
  4. Run a manual execution to test Azure Monitor connectivity and verify the output manifest.

Common pitfalls and troubleshooting

  • Serverfarm vs Web App Resource URI: Ensure the resource URI points to Microsoft.Web/serverfarms for aggregate plan metrics rather than individual Microsoft.Web/sites.
  • Metric Aggregation: Memory percentage on App Service Plans should be evaluated using Maximum to catch peak instance memory spikes across all scaled-out instances.
  • Service Principal Role: Ensure the service principal has Monitoring Reader or Contributor on the hosting resource group.

How to extend

  • Automated Horizontal Scale-Out: Add a downstream task using Azure CLI or REST API to increase instance count by +1 when memory crosses 90%.
  • Automated Heap Dump Collection: Dispatch an Azure Kudu REST API command to capture a memory dump before restarting the affected web app.
  • Multi-Plan Subscription Audit: Wrap the evaluation in an io.kestra.plugin.core.flow.ForEach loop to scan all App Service Plans across production environments.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.