Troubleshooting Architecture Map for Azure Functions¶

This guide is a diagnostic architecture reference for incident response. It is intentionally failure-oriented so you can locate where symptoms originate and what evidence source to check first. Use it as a fast index from symptom category to architecture layer ownership.

Request path architecture (where user-facing failures surface)¶

The request path is where availability and latency symptoms first appear. Most 5xx, timeout, DNS, and auth issues can be mapped to one of these nodes.

flowchart LR
    A[Client] --> B[DNS]
    B --> C[Load Balancer]
    C --> D[Frontend]
    D --> E[Worker Process]
    E --> F[Function Code]
    F --> G[Output Binding]
    G --> H[Downstream]

    B -. DNS failure .-> X1[Name resolution error]
    D -. 401 or 403 auth failure .-> X2[Auth or EasyAuth reject]
    D -. 5xx gateway failure .-> X3[Frontend-generated 5xx]
    E -. timeout .-> X4[Execution timeout]
    G -. 5xx or retry storm .-> X5[Binding write failure]
    H -. timeout or 5xx .-> X6[Dependency failure]

Request-path failure map¶

High-signal KQL for request-path triage¶

requests
| where timestamp > ago(30m)
| summarize
    Total=count(),
    Failed=countif(success == false),
    P95=percentile(duration, 95)
  by resultCode, bin(timestamp, 5m)
| order by timestamp desc

Runtime and worker model (where execution failures originate)¶

Azure Functions execution is split across host and language worker boundaries. Symptoms often appear in requests, but root causes are frequently in process lifecycle and resource pressure.

flowchart TB
    A[Functions Host Process\nTrigger listeners, bindings, scale hooks] --> B[Language Worker Process\nPython, Node.js, Java, .NET isolated]
    B --> C[User Function Code]

    A -. startup failure .-> X1[Host startup failed]
    B -. process crash .-> X2[Worker terminated]
    B -. GIL contention .-> X3[Python throughput collapse]
    A -. memory pressure .-> X4[Recycle or OOM risk]
    C -. blocking call .-> X5[Execution timeout]

Runtime diagnostic table¶

Runtime evidence shortcuts¶

Deployment path (where release regressions appear)¶

Many incidents begin at deployment transitions. Map failures by stage so rollback and forward-fix decisions are evidence-based.

flowchart LR
    A[Code] --> B[Build]
    B --> C[Artifact]
    C --> D[Deploy Target]
    D --> E[Slot]
    E --> F[Production]

    B -. dependency restore failure .-> X1[Build failed]
    C -. runtime mismatch .-> X2[Invalid artifact]
    D -. deploy auth failure .-> X3[Deploy rejected]
    E -. slot config drift .-> X4[Swap risk]
    F -. post-release 5xx .-> X5[Production regression]

Deployment stage troubleshooting table¶

Minimal CLI checks for deployment path¶

az monitor activity-log list \
  --subscription "<subscription-id>" \
  --resource-group "rg-myapp-prod" \
  --offset 2h \
  --max-events 50 \
  --output table

az functionapp deployment slot list \
  --resource-group "rg-myapp-prod" \
  --name "func-myapp-prod" \
  --output table

Network and outbound path (where external connectivity fails)¶

Outbound failures often look like app bugs but originate in network controls. Use this path to separate DNS, routing, NSG, and SNAT issues.

flowchart LR
    A[Function App] --> B[VNet Integration]
    B --> C[Subnet]
    C --> D[NSG]
    D --> E[UDR]
    E --> F[NAT or Firewall]
    F --> G[Internet or Private Endpoint]

    C -. SNAT exhaustion .-> X1[Ephemeral port depletion]
    D -. NSG block .-> X2[Outbound denied]
    E -. UDR misconfiguration .-> X3[Blackhole route]
    F -. firewall deny .-> X4[Egress blocked]
    G -. DNS resolution failure .-> X5[Name lookup failed]

Outbound failure evidence table¶

Observability map (where evidence is collected)¶

This map shows the primary data paths for troubleshooting. During incidents, choose evidence source by hypothesis rather than querying everything.

flowchart LR
    A[Function App] --> B[Application Insights]
    A --> C[Platform Logs]
    B --> D[Log Analytics Workspace]
    C --> D
    D --> E[Queries and Dashboards]
    B -. requests, traces, dependencies, exceptions .-> E
    C -. startup, recycle, platform events .-> E

Observability source matrix¶

Where problems happen (summary)¶

Use this as the first routing table when symptom ownership is unclear.

Suggested incident flow through architecture layers¶

flowchart TD
    A[Symptom detected] --> B{User-facing 5xx or timeout?}
    B -->|Yes| C[Check requests and exceptions]
    B -->|No| D[Check trigger activity and traces]
    C --> E{Downstream latency high?}
    E -->|Yes| F[Inspect dependencies and outbound network path]
    E -->|No| G[Inspect worker and host lifecycle]
    D --> H{No listener startup events?}
    H -->|Yes| I[Investigate host startup and config]
    H -->|No| J[Inspect trigger source and backlog]
    F --> K[Apply smallest safe mitigation]
    G --> K
    I --> K
    J --> K

See Also¶

• First 10 Minutes
• Systematic Troubleshooting Methodology
• KQL Query Library
• Functions not executing playbook
• High latency / slow responses playbook
• Functions failing with errors playbook
• Deployment failures playbook
• Monitoring

Sources¶

• Azure Functions monitoring
• Azure Functions networking options
• Azure Functions scale and hosting
• Application Insights data model
• Azure Monitor Activity Log