Cloud Run traffic routing and prior revision rollback behavior

Yes, traffic shifting to a prior revision can be performed safely without a new deployment or image rebuild. Because Cloud Run revisions are immutable, you can reallocate 100% of traffic to any existing, non-deleted revision via the service traffic configuration. This update modifies the routing table of the service rather than the revision itself.

Rollback Mechanics and Constraints

Cloud Run does not automatically detect container crashes or 5xx errors to trigger a rollback. Traffic remains assigned to the latest revision until an explicit configuration change is made via the Google Cloud Console, gcloud CLI, or the API.

Revision Deletion and Availability

The ability to perform a traffic-based rollback depends entirely on the existence of the target revision. If a revision has been deleted—either manually or via automated cleanup policies—it is permanently removed from the list of routable targets. Deletion immediately invalidates the ability to shift traffic back to that specific version; you cannot "undelete" a revision to restore it to the routing table.

Traffic Propagation and Latency

While traffic reallocation is generally fast, it is not instantaneous. The following behaviors are expected during a shift:

• Propagation: Updates are regional. If you are using a Global External HTTP(S) Load Balancer in front of Cloud Run, there may be a brief window where edge caches or load balancer propagation cause a small number of requests to still reach the failed revision.
• In-flight Requests: Requests already being processed by the failed revision will continue until they complete or time out, regardless of the traffic shift.

Verification and Execution

To shift traffic back to a known stable revision (e.g., stable-revision-name) using the gcloud CLI:

gcloud run services update-traffic [SERVICE_NAME] --to-revisions=stable-revision-name=100 --region=[REGION]

Confirming Traffic Cessation

To verify that traffic has fully ceased reaching the failed revision, monitor these three indicators:

1. Traffic Configuration: Confirm the service configuration explicitly shows 0% allocated to the failed revision.
2. Request Metrics: Check the Cloud Run "Requests" metric filtered by revision; the failed revision should show a trend toward zero new requests.
3. Logs: Monitor the logs for the failed revision. New request entries should stop appearing after the propagation window (typically seconds).

Diagnostic Note: Please specify if you are using a Global Load Balancer or the default .a.run.app URL, as this changes the expected propagation latency for the traffic shift.