diff --git a/docs/developer/release/5-update-release-branch.md b/docs/developer/release/5-update-release-branch.md
deleted file mode 100644
index 2cb91166850f..000000000000
--- a/docs/developer/release/5-update-release-branch.md
+++ /dev/null
@@ -1,20 +0,0 @@
-# Update Release Branch
-
-The `release` branch is a special branch that is used for grafana cloud to point at our install scripts and example kubernetes manifests. This is not to be confused with `release-VERSION_PREFIX` created in [Create Release Branch](./1-create-release-branch.md)
-
-## Before you begin
-
-1. The release tag should exist from completing [Tag Release](./4-tag-release.md)
-
-## Steps
-
-1. Force push the release tag to the `release` branch
-
-    ```
-    git fetch
-    git checkout main
-    git branch -f release VERSION
-    git push -f origin refs/heads/release
-    ```
-
-    > **NOTE**: This requires force push permissions on this branch. If this fails, reach out to one of the project maintainers for help. 
diff --git a/docs/developer/release/README.md b/docs/developer/release/README.md
index 2c87654908f3..27bba296303b 100644
--- a/docs/developer/release/README.md
+++ b/docs/developer/release/README.md
@@ -8,13 +8,13 @@ The processes described here are for v0.24.0 and above.
 
 # Release Cycle
 
-A typical release cycle is to have a Release Candidate published for at least 48 
+A typical release cycle is to have a Release Candidate published for at least 48
 hours followed by a Stable Release. 0 or more Patch Releases may occur between the Stable Release
 and the creation of the next Release Candidate.
 
 # Workflows
 
-Once a release is scheduled, a release shepherd is determined. This person will be 
+Once a release is scheduled, a release shepherd is determined. This person will be
 responsible for ownership of the following workflows:
 
 ## Release Candidate Publish
@@ -39,20 +39,18 @@ responsible for ownership of the following workflows:
 2. [Update Version in Code](./3-update-version-in-code.md)
 3. [Tag Release](./4-tag-release.md)
 4. [Publish Release](./6-publish-release.md)
-5. [Update Release Branch](./5-update-release-branch.md)
-6. [Test Release](./7-test-release.md)
-7. [Update Helm Charts](./8-update-helm-charts.md)
-8. [Announce Release](./9-announce-release.md)
-9. [Update OTEL Contrib](./10-update-otel.md)
+5. [Test Release](./7-test-release.md)
+6. [Update Helm Charts](./8-update-helm-charts.md)
+7. [Announce Release](./9-announce-release.md)
+8. [Update OTEL Contrib](./10-update-otel.md)
 
 ## Patch Release Publish (latest version)
 1. [Cherry Pick Commits](./2-cherry-pick-commits.md)
 2. [Update Version in Code](./3-update-version-in-code.md)
 3. [Tag Release](./4-tag-release.md)
 4. [Publish Release](./6-publish-release.md)
-5. [Update Release Branch](./5-update-release-branch.md) 
-6. [Update Helm Charts](./8-update-helm-charts.md)
-7. [Announce Release](./9-announce-release.md)
+5. [Update Helm Charts](./8-update-helm-charts.md)
+6. [Announce Release](./9-announce-release.md)
 
 ## Patch Release Publish (older version)
 - Not documented yet (but here are some hints)
@@ -61,6 +59,5 @@ responsible for ownership of the following workflows:
   - cherry-pick commit[s] into it
   - don't update the version in the project on main
   - changes go into the changelog under the patch release version plus stay in unreleased
-  - don't update the `release` branch
   - don't publish in github as latest release
   - don't update deployment tools or helm charts