> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/continuous-delivery/3.0/use-deployments/overview-3/gcr-deploy/gcr-rollback.md).

# Google Cloud Run Rollback

Restore the previous Cloud Run traffic distribution after a failed deployment using the Google Cloud Run Rollback step.

The Google Cloud Run Rollback step restores traffic to the revision that was live before the failed deployment. Harness adds this step automatically to the rollback phase of Basic and Canary stages. It runs when the stage failure strategy triggers a stage rollback.

***

## Step YAML

The Rollback step is placed in the stage rollback phase. No `with:` inputs are required; Harness reads the rollback state from the last successful deployment automatically:

```yaml
rollback:
- group:
    steps:
    - name: Google Cloud Run Rollback
      id: googleCloudRunRollbackStep
      template:
        uses: googleCloudRunRollbackStep
  id: googleCloudRunCanaryRollback
  name: Google Cloud Run Canary Rollback
```

For a Basic strategy rollback group, use `id: googleCloudRunBasicRollback` and `name: Google Cloud Run Basic Rollback`.

***

## Before you begin

* This step is automatically added to Basic and Canary stages. You do not need to add it manually unless you are building a custom rollback flow using the blank canvas approach.
* **A Google Cloud Run infrastructure** with a GCP connector and region. Go to [Google Cloud Run infrastructure](/continuous-delivery/3.0/use-deployments/overview-3/google-cloud-run-infrastructure.md).

***

## Configure the step

The Rollback step requires no configuration inputs. Harness automatically reads the revision state saved by the last successful deployment of the stage and uses it to restore traffic.

{% hint style="warning" %}
**Rollback does not delete revisions**

Google Cloud Run does not support deleting a specific revision. Rollback on subsequent deployments diverts traffic to the previous revision rather than removing the newly created one. The canary revision remains in Cloud Run at 0% traffic after rollback.
{% endhint %}

***

## Advanced settings

* **Timeout duration:** Maximum time the step is allowed to run before being terminated.
* **On failure:** Define what happens if the rollback step itself fails.
* **Strategy:** Configure a looping strategy.
* **Conditional execution:** Run this step only when a specified condition is true.

***

## How it runs

When the Rollback step executes, the following sequence occurs:

1. Authenticates with GCP using the configured connector.
2. Configures the gcloud environment: sets project and region.
3. Runs `gcloud run revisions list --service <service> --format json` to enumerate all revisions for the service, including retired ones.
4. Reads `${{rollback.data.REVISION_METADATA}}` to identify the stable revision and traffic distribution from the last successful deployment. For example:

   ```json
   {"status":{"latestCreatedRevisionName":"my-svc-00003-abc","traffic":[{"percent":100,"revisionName":"my-svc-00003-abc"}]}}
   ```
5. Runs `gcloud run services describe <service> --format json` to inspect the live traffic distribution at the time rollback runs (for example, a 50/50 canary split).
6. Checks for Cloud Run URL tags on the service that need to be removed. If none exist, logs "No tags to remove" and proceeds.
7. **If no prior successful deployment exists** (first deployment of the service): runs `gcloud run services delete <service>` to remove the newly created service entirely.
8. **If a prior successful deployment exists**: runs `gcloud run services update-traffic <service> --to-revisions=<stable-revision>=100`. For example:

   ```
   gcloud run services update-traffic my-svc --to-revisions=my-svc-00003-abc=100
   ```

   Cloud Run confirms: `100% my-svc-00003-abc`.
9. Runs `gcloud run services describe <service>` to confirm the restored traffic state and saves the result as `REVISION_METADATA` in step output.
10. Performs instance sync using the Google Cloud Monitoring SDK. If data is found, waits an additional 60 seconds for a stable read.
11. Publishes `INSTANCES` and `DEPLOYMENT_METADATA` to step output. The stage ends in a failed state.

***

## Next steps

* Go to [Google Cloud Run Deploy](/continuous-delivery/3.0/use-deployments/overview-3/gcr-deploy.md) for the step that saves the rollback data this step reads.
* Go to [Basic deployment](/continuous-delivery/3.0/use-deployments/overview-3/basic.md) for the rollback behavior in a basic strategy stage.
* Go to [Canary deployment](/continuous-delivery/3.0/use-deployments/overview-3/basic/canary.md) for the rollback behavior in a canary strategy stage.

{% @harness-feedback/feedback %}