Metric alerts by incident question¶

When an on-call SRE asks "what's the right alert for incident X?", this page maps the question to the exact metric, aggregation, split dimension, and a starting threshold. The page is a selection aid, not an alert-rule tutorial — for CLI syntax, action groups, and Portal capture of alert blades, see Alerting for Container Apps. For metric definitions, denominators, and dimensions, see the Container Apps metrics reference.

Decision path for incident-question-driven metric alerts:

flowchart TD
    Q["Incident question from on-call"] --> M{"Answerable by Container Apps metrics?"}
    M -- yes --> MAP["Map question to metric: replicas, execution, http, resource usage"]
    MAP --> ALERT["Create metric alert with action group"]
    M -- "no — behavioral or trace data" --> LOGS["Use logs or App Insights instead"]
    ALERT --> V["Verification: alert fires with threshold and dimensions as intended"]
    LOGS --> V
    V --> RB["Rollback / Troubleshooting if noisy or silent"]

Prerequisites¶

You already know how to create an Azure Monitor metric alert (az monitor metrics alert create) — that lives in Alerting for Container Apps. This page assumes you are looking for the correct metric and threshold, not the CLI shape.

export RG="rg-myapp"
export APP_NAME="ca-myapp"

When to Use¶

Use this page in three situations:

• Designing a new metric alert — you have an incident question ("what should page me when CPU saturates?") and need to pick the metric, aggregation, and split before writing the az monitor metrics alert create command.
• Evaluating an existing alert's signal-to-noise — your current alert fires too often or never fires, and you want to confirm you chose the right metric and aggregation, or check whether a metric alert is even the right vehicle.
• Incident triage — an alert just fired and you want to confirm what the metric actually measures, what its denominator is, and whether a companion signal (e.g., RestartCount confirming MemoryPercentage) should also have fired.

Skip this page if you need: CLI syntax (see Alerting for Container Apps), threshold-tuning methodology (see Recommended Threshold Baseline), or metric definitions (see the metrics reference).

Procedure¶

1. Scan the Incident question column for the symptom you want to alert on.
2. Check the Use when / Preconditions column — many rows are only valid under specific workload conditions (always-on apps, profile-pinned envs, attached resiliency policies, etc.). Skip rows whose preconditions do not match your app.
3. Click the metric link to confirm the exact dimension names, denominators, and observed-data sample in the Metrics reference.
4. Use the starting threshold as a first draft, then tune from 2-4 weeks of baseline data per the methodology in Alerting for Container Apps → Recommended Threshold Baseline.
5. Write the alert using the CLI shape documented in Azure Monitor alert rules.

Incident question to metric mapping¶

Use logs or App Insights instead¶

Azure Monitor metric alerts on Container Apps platform metrics are the fastest signal (1-2 minute evaluation), but they have hard limits. Use these alternatives when the metric-alert column above cannot express what you need.

Verification¶

Before you commit a new metric-alert rule to production, confirm the metric is actually being emitted for your specific app and that your aggregation produces non-empty values over your window.

1. Confirm the metric is published for your resource (catches metric-typo and preview-metric-not-yet-available errors):

   az monitor metrics list-definitions \
     --resource "/subscriptions/<subscription-id>/resourceGroups/$RG/providers/Microsoft.App/containerApps/$APP_NAME" \
     --query "[?name.value=='CpuPercentage']"
   

   Flag	Purpose
   --resource	Full Azure resource ID of the target container app; metrics list-definitions is resource-scoped, so the shorter --name form is not accepted here.
   --query	JMESPath filter on the response to verify the specific metric ID (CpuPercentage) is actually published for this resource and not just listed in Azure-wide reference docs.

2. Dry-run the aggregation over a recent window to confirm non-empty data and a realistic baseline. The --offset flag accepts portable ##d##h notation (default 1h) and avoids OS-specific date substitutions:

   az monitor metrics list \
     --resource "/subscriptions/<subscription-id>/resourceGroups/$RG/providers/Microsoft.App/containerApps/$APP_NAME" \
     --metric "CpuPercentage" \
     --aggregation Average \
     --interval PT5M \
     --offset 2h
   

   Flag	Purpose
   --resource	Targets the exact Container App resource whose metric stream you plan to alert on, so the dry run reflects the same scope the future alert rule will evaluate.
   --metric "CpuPercentage"	Chooses the specific metric signal under review, which lets the operator confirm that this incident question maps to a real Container Apps metric instead of a guessed name.
   --aggregation Average	Tests the same rollup style an alert would use, which matters because averages can look healthy even when single spikes would have triggered a Maximum-based rule.
   --interval PT5M	Buckets the series into 5-minute windows so you can judge whether the alerting granularity is too coarse or too noisy for incident response.
   --offset 2h	Pulls a recent two-hour sample window, which is long enough to confirm the metric is emitting and to estimate a realistic threshold before you create the alert.

3. After creating the rule, confirm it is firing as expected against historical data by reviewing the rule's Fired alerts tab in the Portal, per Alerting for Container Apps → Portal view.

Rollback / Troubleshooting¶

If your alert misfires (too noisy or silent), the rollback is usually not to disable the rule but to retune the threshold or change the metric. Use this decision order:

• Alert fires too often (false positives) → Re-check the Use when / Preconditions column for your row. Common cause: alerting Replicas == max-replicas without a saturation-signal pairing produces false positives during legitimate load spikes. Adjust by adding the paired signal or by widening the window.
• Alert never fires when you expect it to → Confirm the metric is published for your app via the list-definitions command in the Verification section above. Preview metrics (CpuPercentage, MemoryPercentage, ResponseTime, NodeCount, etc.) may not be available in all regions/SKUs.
• You picked a metric alert but actually need ratio math or log content → Switch to the Use logs or App Insights instead table above and migrate the rule to a log-based or Application Insights alert.
• Environment-wide quota saturation → TotalCoresQuotaUsed is per-app, not per-environment. For env-wide quota use az containerapp env list-usages in a scheduled job; there is no metric alert for this dimension.
• Threshold tuning methodology (collecting 2-4 weeks of baseline before locking thresholds) → Alerting for Container Apps → Recommended Threshold Baseline.

To disable a rule temporarily without deleting it:

az monitor metrics alert update \
  --name "<alert-name>" \
  --resource-group "$RG" \
  --enabled false

What this page does not cover¶

This page is scoped to metric-alert selection. The following are owned by other pages — do not duplicate the configuration here:

• Metric alert CLI syntax (az monitor metrics alert create), action groups, notification channels, severity-to-channel routing → Alerting for Container Apps.
• Log-based and Activity-log alerts (the full KQL alert lifecycle) → Alerting for Container Apps → Log-Based Alerts with KQL and Activity Log Alert Example.
• Portal screenshots of the Alerts blade, Alert rules blade, and Alert rule detail → Alerting for Container Apps → Portal view sections.
• Metric definitions (what each metric measures, denominators, dimensions, observed sample data, capture screenshots) → Container Apps metrics reference.

See Also¶

• Alerting for Container Apps — alert-rule CLI, action groups, baseline thresholds, Portal screenshots
• Container Apps metrics reference — metric IDs, aggregations, dimensions, denominators, observed sample data
• KEDA scaler observability — system-logs-only attribution for scale events
• KEDA scaler metrics (KQL pack)
• Scaling events (KQL pack)
• Observability Operations (monitoring index)
• Recovery and Incident Readiness

Sources¶

• Set alerts in Azure Container Apps
• Monitor metrics in Azure Container Apps
• Service discovery and resiliency in Azure Container Apps
• Types of Azure Monitor alerts
• Application Insights query alerts (Microsoft Learn)