Let’s talk
← All insights
ENGINEERING JOURNAL / Google Cloud Operations

Cloud Run Traffic Splits: Verify the URL Being Tested

Validate Cloud Run rollouts by separating tagged revision tests from service traffic, checking explicit revision allocation, and preparing a usable rollback.

Clouvenix Engineering notes · 4 min read · 20 Oct 2026
Cloud Run Traffic Splits: Verify the URL Being TestedCloud Run Traffic Splits: Verify the URL Being Tested — conceptual 3D-style vector showing Client URL, Service traffic split, Stable revision, Candidate revision, Tag test URL, Outcome metrics.. Conceptual teaching illustration; connections show the investigation flow rather than a vendor deployment topology.CLOUVENIX / GOOGLE CLOUD OPERATIONSCloud Run Traffic Splits: Verify the URL Being Tested01Client URL02Service traffic split03Stable revision04Candidate revision05Tag test URL06Outcome metricsConceptual investigation flow / Cloud Run Traffic Splits: Verify the URL Being Tested
Cloud Run Traffic Splits: Verify the URL Being Tested — conceptual 3D-style vector showing Client URL, Service traffic split, Stable revision, Candidate revision, Tag test URL, Outcome metrics.
Google Cloud OperationsIDEAS → IMPLEMENTATION

Identify which route the request follows

A Cloud Run service can distribute ordinary requests across multiple revisions. A traffic tag provides a separate URL that reaches a particular revision. That makes tags useful for candidate testing, but a successful tagged request does not prove that the ordinary service URL sends traffic to the candidate. Likewise, a candidate with no percentage allocation can still receive tagged requests.

A rollout therefore needs two kinds of evidence: direct validation of the candidate and observation of the service's configured allocation. Keep revision identity in logs and metrics so failures can be attributed to a release rather than averaged across the entire service. Authentication requirements also continue to apply to tagged endpoints.

Before beginning, identify the stable revision, candidate image digest, project, region, expected request mix, and rollback owner. Check compatibility of shared databases and external side effects. Reassigning traffic cannot undo an incompatible schema change or reverse messages already published by the candidate.

Validate the rollout in stages

  1. Read gcloud run services describe storefront --project=PROJECT_ID --region=REGION --format=export. Inspect the traffic section, revision names, tags, and whether allocation follows an explicit revision or a latest-revision target. Confirm the current state before planning a change.
  2. Test the candidate through its intended tagged URL using approved credentials and safe business records. Cover startup, dependencies, and a representative operation. Include a revision identifier in internal diagnostics so the test can demonstrate which release handled it without exposing implementation details to customers.
  3. Apply the reviewed percentage split through the deployment source. Exercise the ordinary service URL and evaluate revision-level error and latency metrics. Use enough traffic to produce useful evidence, while acknowledging that a small sample need not match the configured percentage exactly.
  4. Promote or restore the prior allocation based on explicit acceptance criteria. Verify the resulting traffic configuration after the command completes. Clean up obsolete tags only after confirming that no test automation or operational tool depends on them.

Illustrative scenario

A hypothetical reporting service deploys a candidate with no ordinary traffic and a preview tag. A test runner reports that the release is healthy. Later, an operator expects customer requests to reach that release, but the traffic configuration still assigns the full service allocation to the stable revision. The problem is a missing migration step, not stale DNS or a failed deployment. Direct tagged testing and ordinary traffic verification answer different questions.

ObservationCheckResponse
Preview works, customers see old behaviorOrdinary service traffic allocationApply the intended reviewed split
Candidate errors are hidden in averagesMetrics grouped by revisionEvaluate candidate-specific outcomes
Rollback serves an incompatible applicationDatabase and dependency compatibilityUse the broader recovery plan
Unexpected tagged instances stay warmLegacy revision minimumsReview tags and scaling together

Verify a rollback before you need it

Confirm that the stable revision still exists and can authenticate to current dependencies. Test a safe request against it when appropriate. Document the previous allocation, not merely the word "rollback." A prior deployment may itself have used multiple revisions. After restoring traffic, watch for ongoing candidate work and reconcile any business operations that crossed the transition.

Release operating procedure

Record the candidate digest, revision names, tagged tests, ordinary service checks, acceptance thresholds, and final allocation in the release record. Monitor both user-visible behavior and revision health throughout the observation window. Review tag ownership and minimum-instance effects during cleanup. Rehearse traffic restoration in staging so the team understands its limits before production pressure arrives.

Explore Clouvenix cloud architecture for implementation and operational handover.

Technical reference

rollouts and traffic migration and tagged revision minimums.