Debugging Azure Functions Failures

Reading execution failures in Application Insights

Every Azure Functions invocation creates a request telemetry item in Application Insights. Failed invocations have success == false. Exceptions during execution are logged as exceptions linked to the same operation_Id.

// Find all failed function executions in the last hour
requests
| where timestamp > ago(1h)
| where success == false
| where cloud_RoleName == "myFunctionApp"
| project timestamp, name, duration, resultCode, operation_Id
| order by timestamp desc

// Get the exception detail for a specific failed invocation
let invocationId = "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee";
exceptions
| where operation_Id == invocationId
| project timestamp, type, outerMessage, innermostMessage, details

The innermostMessage field contains the original exception message without the wrapper exceptions that Azure adds. Start there when investigating a failure.

Diagnosing timeout failures

Timeout errors produce a specific message:

Executed 'Functions.MyFunction' (Failed, Id=...)
Microsoft.Azure.WebJobs.Host.FunctionTimeoutException:
The function MyFunction (Id: ...) invoked at 2026-03-19T10:15:00 has exceeded
the configured timeout of 00:05:00. The invocation will be aborted.

The timeout is configured in host.json and defaults to 5 minutes on Consumption plan:

{
  "version": "2.0",
  "functionTimeout": "00:10:00"
}

Before extending the timeout, diagnose where the time is being spent. Add structured logging at each major step:

// Add timing logs to identify slow steps
var sw = Stopwatch.StartNew();
logger.LogInformation("Step 1: Fetching customer data");
var customer = await _customerRepo.GetAsync(customerId);
logger.LogInformation("Step 1 complete in {ElapsedMs}ms", sw.ElapsedMilliseconds);

sw.Restart();
logger.LogInformation("Step 2: Calling payment API");
var result = await _paymentApi.ChargeAsync(customer, amount);
logger.LogInformation("Step 2 complete in {ElapsedMs}ms", sw.ElapsedMilliseconds);

Then query Application Insights for the timing logs to find the slow step:

traces
| where timestamp > ago(1h)
| where message startswith "Step"
| where cloud_RoleName == "myFunctionApp"
| project timestamp, message, customDimensions.ElapsedMs
| order by timestamp asc

Binding errors

Binding errors prevent the function from receiving its input or sending its output. They manifest as exceptions during function setup rather than in the function body:

Microsoft.Azure.WebJobs.Host: Error indexing method 'Functions.ProcessOrder'.
Microsoft.Azure.WebJobs.ServiceBus: Exception while executing function:
Functions.ProcessOrder. Microsoft.Azure.ServiceBus: 40102
- Unauthorized. TrackingId:..., SystemTracker:..., Timestamp:2026-03-19T10:15:00

Common binding error causes and fixes:

# Fix a Service Bus binding: assign the correct RBAC role to the managed identity
PRINCIPAL_ID=$(az functionapp identity show \
  --name myFunctionApp \
  --resource-group myRG \
  --query principalId --output tsv)

az role assignment create \
  --assignee $PRINCIPAL_ID \
  --role "Azure Service Bus Data Receiver" \
  --scope /subscriptions/SUB_ID/resourceGroups/myRG/providers/Microsoft.ServiceBus/namespaces/mySBNamespace/topics/myTopic/subscriptions/mySub

Memory and resource exhaustion

Functions that process large payloads or that have memory leaks can exhaust available memory, causing the worker process to crash. Signs include sudden function restarts, OutOfMemoryException in the logs, or the function host recycling unexpectedly.

// Check for OutOfMemoryException
exceptions
| where timestamp > ago(24h)
| where type contains "OutOfMemoryException" or innermostMessage contains "memory"
| summarize count() by bin(timestamp, 1h), type
| render timechart

// Check average memory usage (from performanceCounters if enabled)
performanceCounters
| where timestamp > ago(1h)
| where name == "Private Bytes"
| summarize avg(value) by bin(timestamp, 5m), cloud_RoleInstance
| render timechart

If memory pressure is confirmed, review code for: streaming vs loading entire files into memory, not disposing HttpClient instances (use IHttpClientFactory), large in-memory collections that grow without bounds, and static variables that accumulate state across invocations (functions share the worker process across invocations on warm instances).

Concurrency and scale-out issues

Azure Functions scales out by adding more instances. If your function code is not thread-safe or if downstream services cannot handle the resulting concurrency, scaling causes failures rather than resolving them.

# Limit concurrency for a Service Bus triggered function in host.json
# This limits the function to processing 4 messages at a time per instance

{
  "version": "2.0",
  "extensions": {
    "serviceBus": {
      "messageHandlerOptions": {
        "maxConcurrentCalls": 4,
        "autoComplete": true,
        "maxAutoRenewDuration": "00:55:00"
      }
    }
  }
}

For HTTP-triggered functions under heavy load, limit max scale-out using the scale controller settings to prevent downstream database connection exhaustion:

# Set maximum scale-out to 10 instances
az functionapp config appsettings set \
  --resource-group myRG \
  --name myFunctionApp \
  --settings WEBSITE_MAX_DYNAMIC_APPLICATION_SCALE_OUT=10

Dependency call failures

Functions often call external dependencies — databases, APIs, storage. Failures in these calls show up as dependency telemetry with success == false:

// Find all failed dependency calls in the last hour
dependencies
| where timestamp > ago(1h)
| where success == false
| where cloud_RoleName == "myFunctionApp"
| summarize count() by target, type, resultCode
| order by count_ desc

// Check if a specific dependency is slow
dependencies
| where timestamp > ago(1h)
| where target contains "mySQLServer"
| summarize avg(duration), percentile(duration, 95), count() by bin(timestamp, 5m)
| render timechart

For database connection failures specifically, check that the connection string is valid, that the database server allows connections from the function app’s IP or VNet, and that the connection pool is not exhausted (use Azure SQL’s active connections metric in the portal to verify).