Azure Functions Skill

Manage and analyze Azure Functions apps using az functionapp and az monitor commands.

Discovery-First Rule

ALWAYS discover before acting. Never assume function app names, resource groups, or plan types.

# Discover all function apps
az functionapp list --output json \
  --query "[].{name:name, rg:resourceGroup, state:state, runtime:siteConfig.linuxFxVersion, kind:kind, plan:appServicePlanId}"

Parallel Execution Requirement

ALL independent operations MUST run in parallel using background jobs (&) and wait.

for app_info in $(echo "$apps" | jq -c '.[]'); do
  {
    name=$(echo "$app_info" | jq -r '.name')
    rg=$(echo "$app_info" | jq -r '.rg')
    az functionapp show --name "$name" --resource-group "$rg" --output json
  } &
done
wait

Helper Functions

# Get function app configuration
get_function_config() {
  local name="$1" rg="$2"
  az functionapp config show --name "$name" --resource-group "$rg" --output json
}

# List functions within an app
list_functions() {
  local name="$1" rg="$2"
  az functionapp function list --name "$name" --resource-group "$rg" --output json \
    --query "[].{name:name, trigger:config.bindings[?direction=='in'] | [0].type, isDisabled:isDisabled}"
}

# Get app settings (masks values)
get_app_settings() {
  local name="$1" rg="$2"
  az functionapp config appsettings list --name "$name" --resource-group "$rg" --output json \
    --query "[].{name:name, slotSetting:slotSetting}"
}

# Get execution metrics
get_execution_metrics() {
  local name="$1" rg="$2" timespan="${3:-PT1H}"
  az monitor metrics list --resource "$name" --resource-group "$rg" \
    --resource-type "Microsoft.Web/sites" --metric "FunctionExecutionCount,FunctionExecutionUnits" \
    --interval PT5M --start-time "$(date -u -v-1H +%Y-%m-%dT%H:%M:%SZ 2>/dev/null || date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%SZ)" \
    --output json
}

Common Operations

1. Function App Health Overview

apps=$(az functionapp list --output json --query "[].{name:name, rg:resourceGroup}")
for app in $(echo "$apps" | jq -c '.[]'); do
  {
    name=$(echo "$app" | jq -r '.name')
    rg=$(echo "$app" | jq -r '.rg')
    az functionapp show --name "$name" --resource-group "$rg" --output json \
      --query "{name:name, state:state, defaultHostName:defaultHostName, runtime:siteConfig.linuxFxVersion, httpsOnly:httpsOnly, ftpsState:siteConfig.ftpsState}"
    list_functions "$name" "$rg"
  } &
done
wait

2. Execution Metrics and Performance

# Get function execution counts and durations
resource_id=$(az functionapp show --name "$APP" --resource-group "$RG" --query "id" -o tsv)
az monitor metrics list --resource "$resource_id" \
  --metric "FunctionExecutionCount" "FunctionExecutionUnits" "Http5xx" "Http4xx" "AverageResponseTime" \
  --interval PT1H --aggregation Total Average --output json

3. Consumption Plan Analysis

# Check hosting plan type and limits
plan_id=$(az functionapp show --name "$APP" --resource-group "$RG" --query "appServicePlanId" -o tsv)
az appservice plan show --ids "$plan_id" --output json \
  --query "{name:name, sku:sku, workers:numberOfWorkers, maxWorkers:maximumElasticWorkerCount, kind:kind}"

4. Scaling Configuration

# Check scale limits for Premium/Dedicated
az functionapp show --name "$APP" --resource-group "$RG" --output json \
  --query "{siteConfig:{preWarmedInstanceCount:siteConfig.preWarmedInstanceCount, functionAppScaleLimit:siteConfig.functionAppScaleLimit, minimumElasticInstanceCount:siteConfig.minimumElasticInstanceCount}}"

# For consumption plan, check daily usage quota
az functionapp show --name "$APP" --resource-group "$RG" --output json \
  --query "{dailyMemoryTimeQuota:dailyMemoryTimeQuota, usageState:usageState}"

5. Deployment and Slot Management

# List deployment slots
az functionapp deployment slot list --name "$APP" --resource-group "$RG" --output json \
  --query "[].{name:name, state:state}"

# Check deployment source
az functionapp deployment source show --name "$APP" --resource-group "$RG" --output json

Output Format

Present results as a structured report:

Azure Functions Report
══════════════════════
Resources discovered: [count]

Resource       Status    Key Metric    Issues
──────────────────────────────────────────────
[name]         [ok/warn] [value]       [findings]

Summary: [total] resources | [ok] healthy | [warn] warnings | [crit] critical
Action Items: [list of prioritized findings]

Target ≤50 lines of output. Use tables for multi-resource comparisons.

Anti-Hallucination Rules

1. NEVER assume resource names — always discover via CLI/API in Phase 1 before referencing in Phase 2.
2. NEVER fabricate metric names or dimensions — verify against the service documentation or --help output.
3. NEVER mix CLI commands between service versions — confirm which version/API you are targeting.
4. ALWAYS use the discovery → verify → analyze chain — every resource referenced must have been discovered first.
5. ALWAYS handle empty results gracefully — an empty response is valid data, not an error to retry.

Counter-Rationalizations

Shortcut	Counter	Why
"I'll skip discovery and check known resources"	Always run Phase 1 discovery first	Resource names change, new resources appear — assumed names cause errors
"The user only asked for a quick check"	Follow the full discovery → analysis flow	Quick checks miss critical issues; structured analysis catches silent failures
"Default configuration is probably fine"	Audit configuration explicitly	Defaults often leave logging, security, and optimization features disabled
"Metrics aren't needed for this"	Always check relevant metrics when available	API/CLI responses show current state; metrics reveal trends and intermittent issues
"I don't have access to that"	Try the command and report the actual error	Assumed permission failures prevent useful investigation; actual errors are informative

Common Pitfalls

1. Consumption vs Premium metrics: Consumption plan does not expose instance count metrics. Use FunctionExecutionCount instead.
2. Cold starts: Premium plan preWarmedInstanceCount reduces cold starts but incurs always-on cost. Check if it is actually needed.
3. Runtime version mismatch: Functions runtime version and language runtime version are separate. Check both FUNCTIONS_EXTENSION_VERSION and language-specific settings.
4. Durable Functions: Orchestrator and activity functions share the same app but have different scaling behaviors. Check Task Hub configuration.
5. CORS and auth: Function-level auth keys are separate from app-level settings. Use az functionapp keys list to audit key exposure.