🐛 Debugging Azure App Service and Functions With AI

The app returned HTTP 500 with a blank body. No stack trace in the response, nothing in the application logs I’d wired up, just a flat error and a pager going off. The cause turned out to be a missing app setting — the connection string the code read at startup wasn’t present in this slot, so the host crashed before any of my logging initialized. App Service swallowed the detail and handed the user a generic 500. Hours of perfectly good debugging time, gone to a config typo.

That’s the App Service and Functions experience: the platform sits between your code and the request, and when something breaks it often eats the useful part of the error. The signal is there, but it’s split across application logs, the platform’s own logs, the Kudu console, and Application Insights. AI is good at reading those scattered, verbose log streams and pointing at the line that matters. It doesn’t fix your app. You pull the logs and decide; it reads them faster than you can scroll.

Turn on the logs that actually exist, then stream them

The first failure is debugging blind because logging was never enabled. Fix that, then tail it live:

az webapp log config --name "$APP" --resource-group "$RG" \
  --application-logging filesystem --level information --detailed-error-messages true

az webapp log tail --name "$APP" --resource-group "$RG"     # live stream

For Functions, the host logs and your function logs interleave, and the host logs are where binding and trigger failures show up. When the stream gets noisy, capture a chunk around the failure and hand it to AI:

Prompt: “Here is an App Service log stream around an HTTP 500. The application’s own logging didn’t print anything. Look for platform-level errors — startup failures, missing configuration, port binding, container exit codes — and tell me whether the host even reached my code. If it crashed before my code, name the most likely cause and the app setting or startup command I should check.”

The distinction AI draws well is did the request reach my code or not. A host that crashed at startup needs a config fix; a request that reached your handler and threw needs a code fix. Knowing which side of that line you’re on saves the most time, and the platform logs make it knowable.

Function won’t trigger: it’s almost always the binding or the host

A Function that deploys cleanly but never fires is a binding problem nine times out of ten — a connection string named wrong, a queue that doesn’t exist, or the host failing to start. Check the host status and the app settings the bindings depend on:

# Are the functions even registered with the host?
az functionapp function list --name "$FUNC_APP" --resource-group "$RG" -o table

# The settings your triggers resolve at runtime
az functionapp config appsettings list --name "$FUNC_APP" --resource-group "$RG" \
  --query "[?contains(name,'CONNECTION') || contains(name,'AzureWebJobs')].name" -o table

A blob or queue trigger reads its connection from an app setting named in the binding — if function.json says "connection": "MyStorage", there must be an app setting MyStorage. Feed the binding and the settings list to AI:

Prompt: “Here is a Function’s function.json with a queue trigger and the list of app setting names on the Function App. The function deployed but never triggers. Cross-reference the binding’s connection and queueName against the settings. Is the connection setting present and correctly named? List anything the binding references that’s missing from the settings.”

This is a mechanical cross-reference that’s easy to botch by eye when names are close (MyStorageConnection vs MyStorage_Connection). AI catches the mismatch; you confirm against the live setting.

Application Insights is where the truth lives

If you have App Insights wired up — and you should — the failures, dependencies, and exceptions are queryable with KQL, which beats scrolling logs. This pulls the recent failures with their actual exception detail:

exceptions
| where timestamp > ago(1h)
| project timestamp, problemId, type, outerMessage, operation_Name, cloud_RoleInstance
| order by timestamp desc
| take 25

And this finds the slow dependency behind a timeout — usually a downstream call, not your code:

dependencies
| where timestamp > ago(1h) and success == false
| summarize count(), avg(duration) by target, name
| order by count_ desc

Don’t memorize the schema. Ask AI to draft the query and explain it:

Prompt: “Write a KQL query against Application Insights requests and exceptions tables to find HTTP 500 responses in the last hour and join each to the exception thrown during that operation, so I see the request URL and the exception message together. Explain the join key.”

The join key is operation_Id, and that correlated view — request plus the exception it triggered — is exactly what the flat log stream couldn’t give you. Verify the table and column names against your workspace; App Insights schemas are stable but AI sometimes reaches for a Log Analytics column that isn’t there.

Cold starts and timeouts: know your plan

A Function that “randomly” times out on the Consumption plan is often a cold start colliding with a short client timeout, or a long-running job that exceeds the plan’s execution limit. The plan determines the ceiling:

az functionapp show --name "$FUNC_APP" --resource-group "$RG" \
  --query "{plan:appServicePlanId, kind:kind, state:state}" -o tsv

Describe the symptom to AI with the plan type and let it map symptom to platform constraint: “Consumption plan, HTTP-triggered Function, fails intermittently after ~230 seconds.” It’ll point straight at the platform’s request timeout and the cold-start-on-scale behavior, and walk you through whether the fix is moving to a Premium plan, enabling Always On (App Service plans only), or making the work asynchronous. These limits are documented and fixed — AI recalls them accurately because they’re not a judgment call.

Stay in control

The throughline: AI reads the scattered logs and KQL, you decide and change. Resist the urge to let it suggest “just restart the app” as a fix before you’ve found the cause — a restart that clears a transient error also clears your evidence, and you’ll be back. The reliable loop is enable detailed logging, reproduce, let AI tell you whether the host or your code failed, fix the one thing, and confirm with a targeted App Insights query. App Service and Functions fail in a small, well-trodden set of ways — missing settings, misnamed bindings, plan limits, cold starts — and that predictability is what makes an LLM a fast, accurate reader of the noise.

My App Service and Functions debugging prompts are in the prompts library, and there’s more in the Azure category. The platform hides the error on purpose; let the model dig it back out while you keep the decisions.