Cloud Run and Cloud Monitoring alert scoping across traffic-split revisions

Direct answers

1. Yes. Scope the alert condition at the service level using resource.label.service_name and do not filter or group by revision_name. One policy then covers every active revision receiving traffic under the split.
2. Set missing-data handling to ignore absent data. Do not treat missing intervals as zero or as a failure, because scale-to-zero produces genuine gaps.
3. Yes. Because the condition is not pinned to a revision, a newly deployed revision that enters the traffic split is automatically included in the service-level aggregation. No policy edit is required.

Working assumptions and uncertainty

Item	Status	Notes
Cloud Run emits per-revision metrics under cloud_run_revision	Assumed from brief	Verify in Metrics Explorer for your project.
Service-level grouping covers traffic-split revisions	Assumed from brief	Group by service_name; omit revision_name.
Scale-to-zero creates missing metric intervals	Assumed from brief	Missing-data setting must be configured before notifications are enabled.
New revision is included automatically	Likely	Expected from service-scoped filter; verify after deployment.
Cloud Run for Anthos uses the same labels	Uncertain	May require a different resource type or label set.

Steps for this case

1. In Cloud Monitoring, create an alert policy and select metric run.googleapis.com/request_latencies (or request_count for error rate).
2. Set resource type to cloud_run_revision.
3. Configure aggregation to group by service_name, and add location only if the service is multi-region. Do not include revision_name.
4. Set the threshold on the aggregated service signal.
5. Set missing-data treatment to ignore missing data.
6. Add a notification channel and save the policy.

Verification

1. In Metrics Explorer, chart run.googleapis.com/request_latencies for resource cloud_run_revision, grouped by service_name. Confirm every revision in the traffic split appears in the aggregated line.
2. Deploy a new revision with a small traffic percentage and confirm its data appears in the same chart without editing the alert.
3. Scale the service to zero for longer than the alignment period and confirm the alert does not fire; then send one request and confirm evaluation resumes.

gcloud run services describe SERVICE --region=REGION --format="value(status.latestCreatedRevisionName)"

Missing diagnostic detail

Are you using fully managed Cloud Run or Cloud Run for Anthos? This determines the correct resource type and service label for the alert filter.