Skip to content

Workload Profile Mismatch

Symptom

An app assigned to a dedicated workload profile fails to start, remains stuck in provisioning, or returns errors such as WorkloadProfileMaximumCoresConstraint. The requested replicas or resources do not land successfully even though the app definition itself looks valid.

flowchart TD
    A[Deploy or scale app on workload profile] --> B[Azure checks profile type and node capacity]
    B --> C{Replica requests fit profile?}
    C -->|Yes| D[Replicas schedule successfully]
    C -->|No| E[Provisioning stalls or profile constraint error]
    E --> F[Inspect app resource request and profile min or max nodes]
    F --> G[Resize app or move to correct profile]

Possible Causes

  • The app is pinned to a workload profile whose node type is too small for the requested CPU or memory.
  • maximumCount is too low to host the requested replica count.
  • minimumCount and maximumCount were misconfigured during environment updates.
  • A cost-optimization change shrank dedicated capacity without checking the app's actual runtime footprint.

Diagnosis Steps

  1. Identify the workload profile the app is using and the per-replica resource request:
az containerapp show \
    --name "$APP_NAME" \
    --resource-group "$RG" \
    --query "{workloadProfile:properties.workloadProfileName,cpu:properties.template.containers[0].resources.cpu,memory:properties.template.containers[0].resources.memory,minReplicas:properties.template.scale.minReplicas,maxReplicas:properties.template.scale.maxReplicas}" \
    --output json
  1. List workload profiles on the environment:
az containerapp env workload-profile list \
    --name "$CONTAINER_ENV" \
    --resource-group "$RG"
  1. Inspect the specific profile that should host the app:
az containerapp env workload-profile show \
    --name "$CONTAINER_ENV" \
    --resource-group "$RG" \
    --workload-profile-name "general-purpose"
Command Why it is used
az containerapp show --query "{workloadProfile:...,cpu:...,memory:...,minReplicas:...,maxReplicas:...}" Confirms the app-to-profile binding and the exact per-replica demand.
az containerapp env workload-profile list Shows every workload profile available in the environment.
az containerapp env workload-profile show --workload-profile-name "general-purpose" Verifies profile settings such as current node range and type.
  1. Compare replica demand (cpu × expected replicas) with the profile's available nodes.
  2. If the app requests more than the profile can place, treat the issue as sizing mismatch rather than application failure.

Resolution

  1. Increase profile capacity if the current profile is correct but too small:
az containerapp env workload-profile update \
    --name "$CONTAINER_ENV" \
    --resource-group "$RG" \
    --workload-profile-name "general-purpose" \
    --min-nodes 1 \
    --max-nodes 5
  1. Reduce app demand if the profile should stay small:
az containerapp update \
    --name "$APP_NAME" \
    --resource-group "$RG" \
    --cpu 0.5 \
    --memory "1Gi" \
    --min-replicas 1 \
    --max-replicas 2
  1. Move the workload to a more appropriate profile or to Consumption when burst economics matter more than always-reserved capacity.
Command Why it is used
az containerapp env workload-profile update --min-nodes 1 --max-nodes 5 Expands dedicated capacity so the environment can place the app's replicas.
az containerapp update --cpu 0.5 --memory "1Gi" --min-replicas 1 --max-replicas 2 Shrinks the app request so it fits the existing profile.

Prevention

  • Validate workload profile sizing before reducing max-nodes for cost reasons.
  • Keep a sizing table for each production app that maps per-replica resources to profile capacity.
  • Review dedicated profile changes together with app scale settings, not as separate cost-only changes.
  • Use Consumption for bursty or uncertain workloads until steady-state demand is proven.

See Also

Sources