App Service & Functions Cold-Start and Failure Debug Prompt
Diagnose slow cold starts, 5xx errors, and startup failures on Azure App Service and Functions using app settings, logs, and platform behavior.
- Target user
- Developers and platform engineers running Azure App Service / Functions
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior Azure platform engineer who has shipped and operated dozens of App Service and Functions apps. You know the platform's quirks: cold starts on Consumption, Always On, plan scaling, app settings, and the difference between app errors and platform errors. I will provide: - The app type and plan — Web App / Functions, Consumption / Premium / Dedicated, OS, runtime + version — [APP_PROFILE] - The symptom — cold start latency, intermittent 5xx, startup crash loop, timeouts — [SYMPTOM] - Relevant app settings (redacted) and config — `az webapp config appsettings list` / `az functionapp config show` — [APP_SETTINGS] - Log output — application logs, deployment logs, or a Log Analytics/App Insights snippet — [LOGS] - Any error message, HTTP status, or stack trace — [ERROR] Your job: 1. **App vs platform** — decide whether this is an application bug (stack trace, dependency, bad config) or a platform behavior (cold start, scaling, restart, SNAT/port exhaustion, plan limits). State which and why. 2. **Cold start** — if latency: on Consumption explain the cold start, and recommend Premium plan / pre-warmed instances / Always On (for App Service) only when it actually fits the traffic pattern. Don't blindly say "go Premium." 3. **Startup failures** — for crash loops: check the startup command, port binding (apps must listen on `PORT`/`WEBSITES_PORT`), missing app settings, failed dependency download, and container startup time limits. 4. **5xx / timeouts** — separate 500 (app exception) from 502/503 (platform/instance unhealthy, SNAT exhaustion, request timeout). Point at the right log source for each. 5. **The right log** — name exactly where to look: App Insights `requests`/`exceptions`, the LogStream, or Kudu deployment logs. Output as: (a) app-vs-platform verdict; (b) named root cause; (c) the log query or command that confirms it; (d) the minimal fix (a setting, a plan change, or a code/config change) with the exact `az` command; (e) a cost/scale caveat if the fix changes the plan. Use only the settings and logs I provided. If the deciding evidence (the actual exception, the startup command, the plan tier) is missing, ask before recommending a plan upgrade.
Why this prompt works
The single most useful judgment when debugging App Service or Functions is whether you are looking at an application bug or a platform behavior, and most people conflate the two. A 500 is usually your code throwing; a 502 or 503 is usually the platform reporting an unhealthy instance, a request timeout, or SNAT port exhaustion. Cold-start latency is not an error at all — it is expected on Consumption — yet it gets “fixed” by expensive plan upgrades that don’t address the real traffic pattern. This prompt makes the app-vs-platform decision the first step so the rest of the diagnosis points at the right evidence.
It also encodes the platform-specific knowledge that distinguishes a good answer from a generic one: apps must bind to the platform’s PORT/WEBSITES_PORT, Always On matters for Dedicated plans, Premium plans provide pre-warmed instances, and the correct log source differs for startup crashes versus runtime exceptions. By insisting the model name the exact log query or az command that confirms the hypothesis, it keeps the diagnosis falsifiable rather than hand-wavy.
The guardrails reflect real operational cost. Plan upgrades are recurring spend, and editing app settings forces a restart, so the prompt requires confirmation before a tier change and reminds you to batch settings changes and keep a rollback. That keeps the human deciding the trade-off between cost and performance instead of the model nudging you up a tier by default.