criticalIntermediateRED#app-service#503#oom#worker-process#recycle

App Service returning 503 — Out of Memory or worker recycle

HTTP 503 returned on the default .azurewebsites.net domain

Likely source:availabilityperformance

Focused incident mode — strips away everything but this runbook.

Symptoms

  • HTTP 503 returned on the default .azurewebsites.net domain
  • App Service logs show worker process recycling or OutOfMemoryException
  • Application Insights shows a spike in failed requests followed by recovery

App Service worker processes recycle silently when they hit memory limits — there is no alert by default. Set up memory alerts via Azure Monitor.

Evidence to grab

Collect these artifacts before you change anything — they prove (or rule out) each cause.

  • App Service diagnostic logs

    az webapp log tail --name <APP> --resource-group <RG> --subscription <SUBSCRIPTION>

  • App state

    az webapp show --name <APP> --resource-group <RG> --query state -o tsv

Diagnostic flow

Run the steps in order, marking each claim confirmed or refuted. The evidence you gather feeds the ranked causes below.

Guided decision tree is ready.

Steps with commands, expected output, and pass/fail branches.

Ranked root causes

Evidence checklist

  • MemoryWorkingSet at or near the plan's limit
  • OutOfMemoryException in application logs
  • Worker process restart correlates with 503 spike

Confirm before fixing

az monitor metrics list --resource <APP-RESOURCE-ID> --metric "MemoryWorkingSet" --interval PT1M --query "value[0].timeseries[0].data[-5:]" -o json
READ

Check current memory usage

Fix

az appservice plan update --name <PLAN> --resource-group <RG> --sku P1v3
CHANGE

Upgrade the App Service plan to a higher tier

Expected: App Service plan updated

Resolution runbook

Apply from top to bottom after the cause is confirmed. Review every command before running it — risk tags are shown on each.

1
az webapp show --name <APP> --resource-group <RG> --query state -o tsv
READ

Check app state

2
az webapp log tail --name <APP> --resource-group <RG> | tail -30
READ

Read the latest logs for OOM

3
az monitor metrics list --resource <APP-RESOURCE-ID> --metric "MemoryWorkingSet" --interval PT1M --query "value[0].timeseries[0].data[-5:]" -o json
READ

Check memory usage trend

4
az appservice plan update --name <PLAN> --resource-group <RG> --sku P1v3
CHANGE

Upgrade the plan if memory is insufficient

Prevention

  • Enable Always On on all production App Service plans (Standard tier or higher).
  • Set up Azure Monitor alerts on MemoryWorkingSet exceeding 80 percent of plan limit.
  • Use Application Insights for memory leak detection and proactive diagnostics.
  • Right-size the App Service plan based on actual memory usage patterns.

Related runbooks

Same stack, same failure family — worth a skim.

App Service frequent recycling — Always On disabled or scale-out thrashhigh

App recycles every few minutes with no code change

AzureIntermediateRED2 causes
Open runbook
OOMKilled containers — memory limit exceededcritical

Exit code 137 on the container

KubernetesFoundationUSE3 causes
Open runbook

Commands marked READ CHANGE DESTRUCTIVE — never run DESTRUCTIVE commands against production data you cannot restore. Copy → verify → execute.