Container App Metrics (Microsoft.App/containerapps)¶

The metric IDs below are the values you pass to az monitor metrics list --metric or select from the Metric dropdown in the Portal Metrics blade. Dimensions are reproduced verbatim from Microsoft Learn.

What each metric means¶

The catalog tables above are the lookup index. This section explains, in plain language, what each metric actually measures, when it moves, what a normal value looks like, and which playbook to open when it goes wrong. The numeric examples are drawn from a live load test described in How these numbers were produced.

UsageNanoCores — CPU Usage¶

Absolute CPU consumption of a replica, reported in nanocores (1 vCPU = 1,000,000,000 nanocores). This is the raw numerator behind CpuPercentage. A replica configured with --cpu 0.5 is allowed to burn up to 500,000,000 nanocores before the kernel throttles it.

Pair with CpuPercentage to know whether a high absolute value means "working hard" (low percentage) or "throttled" (near-100% percentage). See CPU throttling playbook.

Captures¶

Baseline view of UsageNanoCores on ca-loadtest-d38538 during the load test — no split, Avg aggregation, Last 24 hours. The aggregated per-bucket average peaks at 495,799,661 nanocores (~0.495 vCPU), consistent with replicas running near their 0.5 vCPU limit.

WorkingSetBytes — Memory Working Set Bytes¶

Resident set size of the container process — the amount of physical memory the kernel is currently keeping in RAM for this replica. This is the numerator behind MemoryPercentage. It includes anonymous pages (heap, stack), file-backed pages that are mapped and active, but excludes swapped-out pages and unreferenced file cache.

A monotonically rising WorkingSetBytes curve over hours is the classical signature of a memory leak. See Memory leak OOMKilled playbook.

Captures¶

Baseline view of WorkingSetBytes on ca-loadtest-d38538 — no split, Avg aggregation. The per-bucket average stabilizes around ~790 MB (≈753 MiB) of resident set against the configured 1 GiB memory limit.

RxBytes — Network In Bytes¶

Cumulative bytes received by the replica's network namespace during the aggregation interval, summed across all interfaces. This is total inbound network volume, not just HTTP request bodies — it includes TCP/TLS overhead, health-probe traffic, and intra-environment service-to-service calls.

Captures¶

Baseline view of RxBytes on ca-loadtest-d38538 — no split, Total aggregation over 5-minute buckets. The per-bucket total shows the aggregate inbound network volume across all replicas under sustained load.

TxBytes — Network Out Bytes¶

Cumulative bytes transmitted by the replica's network namespace during the aggregation interval. Includes response bodies, TLS handshake bytes, downstream API calls the replica initiates, and Container Apps platform telemetry the data plane emits.

Because the response side typically dwarfs the request side for web traffic, TxBytes is usually 10-100× RxBytes on a healthy API.

Captures¶

Baseline view of TxBytes on ca-loadtest-d38538 — no split, Total aggregation. The per-bucket total reflects aggregate outbound bytes (response payloads + downstream calls + telemetry) across all replicas.

Replicas — Replica count¶

How many replicas were running for a revision at each sample point. This is the most direct evidence of scaler behavior: every scale-out adds a step, every scale-in removes one.

If Requests is climbing but Replicas is not, see HTTP scaling not triggering playbook. If you need to know which scaler caused a replica change, see KEDA scaler observability.

Captures¶

Baseline view of Replicas on ca-loadtest-d38538 — no split, Maximum aggregation. The chart shows the staircase pattern of scale-out from the min-replicas=2 floor toward the max-replicas=10 ceiling as the HTTP scaler crosses its concurrentRequests=20 threshold under load, then a slower scale-in once load subsides.

RestartCount — Total Replica Restart Count¶

Number of times a replica's main container has been restarted by the Container Apps data plane. Restarts happen when the container exits non-zero, the liveness probe fails, the kernel OOM-kills the process, or the data plane recycles the replica during a controlled event.

Any non-zero value warrants investigation. See Crashloop OOM and resource pressure playbook and Probe failure and slow start playbook.

Captures¶

Baseline view of RestartCount on ca-crashloop-d38538 — no split, Maximum aggregation. The test app's memory-growth loop pushes each replica past its --memory 0.5Gi cgroup limit, the kernel OOM-killer terminates the container, and the platform restarts it; the running maximum across the test window climbs to Max=104.

Requests — Requests¶

HTTP request count observed at the ingress layer (Envoy) for the revision. Each request is counted exactly once even if the resiliency policy retries it internally — the retries are counted under ResiliencyRequestRetries, not duplicated here.

Splitting by statusCodeCategory is the single most useful operational view for catching error spikes:

az monitor metrics list \
    --resource "$RES_ID" \
    --metric Requests \
    --aggregation Total \
    --interval PT5M \
    --filter "statusCodeCategory eq '*'" \
    --output table

Captures¶

Baseline view of Requests on ca-loadtest-d38538 — no split, Total aggregation. The chart shows the aggregate request rate (sum across all replicas, all status codes) sustained around ~7,000-8,000 requests per minute during the load test.

CoresQuotaUsed — Reserved Cores (per revision)¶

Aggregate vCPU reservation for a single revision, calculated as replicas × cpu-per-replica. This is a reservation, not a consumption — it reflects how many cores the data plane has earmarked for the revision to satisfy its current replica count and per-replica CPU request, regardless of whether the replicas are actually doing work.

Captures¶

Baseline view of CoresQuotaUsed on ca-loadtest-d38538 — no split, Maximum aggregation. The chart steps up as the HTTP scaler adds replicas: each 0.5 vCPU replica added bumps the reservation up by 0.5, producing a visible staircase from 1.0 at the 2-replica floor (--min-replicas 2 × --cpu 0.5) to 5.0 at the 10-replica peak.

TotalCoresQuotaUsed — Total Reserved Cores (per container app)¶

Total cores currently reserved for this container app, summed across all of its active revisions and replicas. Microsoft Learn defines this metric on the Microsoft.App/containerapps namespace as "Total cores reserved for the container app" — it is per-resource, not per-subscription, despite the word "Total" in the display name.

Captures¶

TotalCoresQuotaUsed is present in the Portal Metrics blade dropdown for any individual container app and renders as a single flat or step line — visually identical to CoresQuotaUsed on a single-revision app. A separate Portal screenshot adds little beyond the CoresQuotaUsed capture above. For programmatic use, the canonical query is:

az monitor metrics list \
    --resource "/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$RG/providers/Microsoft.App/containerApps/$APP_NAME" \
    --metric TotalCoresQuotaUsed \
    --aggregation Maximum \
    --interval PT5M \
    --output table

For per-environment consumption against quota (the number Azure's enforcement actually checks), use az containerapp env list-usages instead — that surface is not a platform metric.

Resiliency metrics — overview¶

The six Resiliency* metrics are emitted by the per-app Envoy sidecar only when a resiliency policy is attached to the receiving app and the traffic originates inside the same Container Apps Environment (via service discovery, not the public FQDN). They are silent for external traffic because the public ingress is a separate Envoy that does not apply the per-app resiliency policy.

To populate these metrics you need:

1. A target app with an internal-only ingress (--ingress internal).
2. A resiliency policy attached to the target via az containerapp resiliency create or equivalent ARM.
3. A caller app in the same environment calling the target by its simple hostname on port 80 (e.g., http://target-app/).

See Service-to-service connectivity failure playbook for the troubleshooting flow when these metrics stay at zero despite a policy being attached.

ResiliencyConnectTimeouts — Resiliency Connection Timeouts¶

Number of upstream TCP connections that exceeded the resiliency policy's timeoutPolicy.connectionTimeoutInSeconds while trying to establish. This counts connect-phase timeouts only — request-phase hangs are counted by ResiliencyRequestTimeouts.

A non-zero value in production typically means the upstream replica died and the data plane has not yet removed it from the endpoint slice — see Service-to-service connectivity failure playbook. Treat any sustained non-zero reading as a request to investigate upstream health, not as a normal background level.

Captures¶

Baseline view of ResiliencyConnectTimeouts on ca-res-blackhole — no split, Total aggregation. The chart is flat at zero throughout the test window because the test target accepts TCP handshakes (see explanation under Sample observed). A non-zero value here would mean SYN packets are being silently dropped at L3 before reaching the destination.

This metric has a revisionName split dimension, but with the value pinned at zero across all revisions the split would render an identical empty chart — omitted here.

ResiliencyEjectedHosts — Resiliency Ejected Hosts¶

Current number of upstream replicas that the resiliency policy's outlier detection has temporarily ejected from the load-balancing pool. Ejection happens after consecutive errors from a replica exceed the policy's threshold (circuitBreakerPolicy.consecutiveErrors).

This metric is the early-warning system for replica health. A persistently non-zero value means traffic is being concentrated on fewer healthy replicas than configured, raising load on the survivors.

Captures¶

Baseline view of ResiliencyEjectedHosts on ca-res-503 — no split, Maximum aggregation. The chart sits at Max=1 across the entire test window: outlier detection keeps ejecting and re-admitting the unhealthy replica, but maxEjectionPercent: 50 of 2 replicas caps the simultaneous-ejection count at 1.

ResiliencyEjectionsAborted — Resiliency Ejections Aborted¶

Number of times the outlier detector wanted to eject a replica but was blocked because doing so would exceed circuitBreakerPolicy.maxEjectionPercent. By design, the policy refuses to eject all replicas because that would leave the caller with nowhere to send traffic — a state colloquially called a brown-out (the upstream is mostly unhealthy but the caller cannot stop sending to it without losing all capacity).

A high ResiliencyEjectionsAborted value alongside non-zero ResiliencyEjectedHosts is the smoking gun for the brown-out state: your upstream is mostly unhealthy and traffic is being concentrated on a small surviving subset. This is a signal to scale the upstream or shed traffic.

Captures¶

Baseline view of ResiliencyEjectionsAborted on ca-res-503 — no split, Total aggregation. The counter climbs steadily as both replicas of ca-res-503 serve constant 503: outlier detection tries to eject the second replica, hits the maxEjectionPercent: 50 safety cap (max 1 of 2 replicas ejectable), and increments EjectionsAborted on every blocked attempt. Cumulative total reached 7,329 across the test window.

ResiliencyRequestRetries — Resiliency Request Retries¶

Number of additional request attempts the resiliency policy has issued on top of the original request. A retry policy with httpRetryPolicy.maxRetries: 2 can produce up to 2 additional attempts per failing original request, so a single observed external 5xx may appear as up to 3 attempts in this counter (1 original + 2 retries).

A sudden climb in ResiliencyRequestRetries is often the first signal that an upstream is degrading — the caller's success rate may still look fine because retries are hiding the failure, but capacity is being consumed disproportionately. Alert on rate of retries, not absolute count.

Captures¶

Baseline view of ResiliencyRequestRetries on ca-res-503 — no split, Total aggregation. The counter climbs steadily because every original request to ca-res-503 returns 503, which matches httpRetryPolicy.matches.errors: ['5xx']; each failing original triggers up to httpRetryPolicy.maxRetries: 2 additional attempts. Cumulative total reached 9,636 retries across the 2-hour test window.

ResiliencyRequestTimeouts — Resiliency Request Timeouts¶

Number of requests that exceeded the policy's timeoutPolicy.responseTimeoutInSeconds (per-request response budget) while waiting for the upstream to respond. This is the request-phase timeout (server slow to respond), distinct from ResiliencyConnectTimeouts (couldn't even open the TCP connection).

Captures¶

Baseline view of ResiliencyRequestTimeouts on ca-res-slow — no split, Total aggregation. Every caller request to /slow?ms=4000 blows past the policy's 1-second response budget, producing a steady climb. Cumulative total reached 1,100 timeouts across the test window.

ResiliencyRequestsPendingConnectionPool — Resiliency Requests Pending Connection Pool¶

Number of requests queued in the per-target connection pool waiting for either an existing connection to become free or a new connection to be opened (up to tcpConnectionPool.maxConnections). Once httpConnectionPool.http1MaxPendingRequests is hit, additional requests fail fast with a circuit-breaker rejection rather than queuing further.

A persistently non-zero value is a sign your circuit-breaker policy is being exercised. That is by design — the policy is protecting your caller from a slow upstream — but it also means user-visible latency is climbing. Pair this metric with a downstream latency SLI.

Captures¶

Baseline view of ResiliencyRequestsPendingConnectionPool on ca-res-pool — no split, Maximum aggregation. With http1MaxPendingRequests: 1 and a flood of concurrent calls from ca-res-caller, the queue depth gauge stays near its cap throughout the test; per-bucket maximum reached 10,488 pending requests at peak.

ResponseTime — Average Response Time (Preview)¶

End-to-end latency observed at the ingress proxy, measured from "request received" to "last response byte sent". Includes time the request spent in the connection pool queue, time the upstream replica spent generating the response, and time spent serializing the response back to the client.

Be aware that this is a Preview metric — Microsoft Learn flags it as not yet GA. Average is a lossy summary; a long tail of slow responses can be hidden by many fast ones. Cross-check with Application Insights requests | summarize percentile(duration, 99) by bin(timestamp, 5m) for percentile views.

Captures¶

Baseline view of ResponseTime on ca-loadtest-d38538 — no split, Average aggregation. The chart shows the mixed-workload average response time during the load test, with sustained averages climbing into the seconds when the /slow?ms=1500 endpoint contributes to the mix.

CpuPercentage — CPU Usage Percentage (Preview)¶

UsageNanoCores ÷ (configured CPU limit in nanocores) × 100. The denominator is the per-replica CPU limit you set with --cpu, not the node's total CPU.

See CPU throttling playbook for diagnosing the throttling case. Preview — do not rely on this as the sole SLO source.

Captures¶

Baseline view of CpuPercentage on ca-loadtest-d38538 — no split, Average aggregation. Replicas serving the /cpu?ms=400 endpoint saturate their 0.5 vCPU allotment; the aggregated per-bucket average peaks at 100.7% (the slight overshoot above 100% is a sampling artifact, not actual over-budget execution — CFS quota caps the actual scheduler at exactly 100%).

MemoryPercentage — Memory Percentage (Preview)¶

WorkingSetBytes ÷ (configured memory limit in bytes) × 100. The denominator is the per-replica memory limit you set with --memory, not the node's total memory.

This is the metric to alert on for memory headroom. As a starting point, page when Average > 80% for 15m, escalate when Maximum > 95% for any window — then tune against your own baseline working set. See Memory leak OOMKilled playbook.

Captures¶

Baseline view of MemoryPercentage on ca-loadtest-d38538 — no split, Average aggregation. Replicas under sustained load hold ~742 MiB working set against the 1 GiB memory limit, producing a per-bucket maximum of 72.5%. The chart trends flat at this plateau because the test workload reaches steady-state allocation rather than leaking.

GpuUtilizationPercentage — GPU Utilization Percentage (Preview)¶

Per-replica GPU utilization for container apps running on workload profiles that expose a GPU (currently the Consumption-GPU-NC8as-T4, Consumption-GPU-NC24-A100, NC8as-T4, NC24-A100, and similar GPU-equipped profiles). The metric is published only when the app is scheduled on a GPU-capable workload profile and the replica's CUDA driver surface has reported utilization to the data plane.

This metric is the primary saturation signal for AI inference workloads on Container Apps. Pair with Requests (request rate) and ResponseTime (latency) to distinguish "GPU is the bottleneck" from "CPU-bound preprocessing is the bottleneck" — if Requests rises but GpuUtilizationPercentage stays flat, the inference loop is not the constraint.

Captures¶

No live Portal capture is included in this pass because the test environment (cae-wp-d38538) was provisioned with general-purpose D4 profiles only, not GPU profiles, so the metric reports no values. The Portal Metrics blade dropdown will still surface this metric for any container app scope, but the chart renders empty when no GPU-scheduled replica is publishing readings.

See Also¶

• Metrics Overview
• Container App Metrics
• Environment Metrics
• Percentage Metrics
• Dimensions
• KEDA Observability
• Evidence and Captures

Sources¶

• Supported metrics for Microsoft.App/containerapps (Microsoft Learn)
• Supported metrics for Microsoft.App/managedEnvironments (Microsoft Learn)
• Azure Monitor metrics overview (Microsoft Learn)