diff --git a/doc/releases.md b/doc/releases.md
index 76f6ad57412ab7..37018e1b3fd002 100644
--- a/doc/releases.md
+++ b/doc/releases.md
@@ -498,17 +498,6 @@ $ git secure-tag <vx.y.z> <commit-sha> -sm "YYYY-MM-DD Node.js vx.y.z (<release-
 The tag **must** be signed using the GPG key that's listed for you on the
 project README.
 
-Push the tag to the repo before you promote the builds. If you haven't pushed
-your tag first, then build promotion won't work properly. Push the tag using the
-following command:
-
-```console
-$ git push <remote> <vx.y.z>
-```
-
-*Note*: Please do not push the tag unless you are ready to complete the
-remainder of the release steps.
-
 ### 12. Set Up For the Next Release
 
 On release proposal branch, edit `src/node_version.h` again and:
@@ -547,7 +536,20 @@ cherry-pick the "Working on vx.y.z" commit to `master`.
 Run `make lint` before pushing to `master`, to make sure the Changelog
 formatting passes the lint rules on `master`.
 
-### 13. Promote and Sign the Release Builds
+### 13. Push the release tag
+
+Push the tag to the repo before you promote the builds. If you haven't pushed
+your tag first, then build promotion won't work properly. Push the tag using the
+following command:
+
+```console
+$ git push <remote> <vx.y.z>
+```
+
+*Note*: Please do not push the tag unless you are ready to complete the
+remainder of the release steps.
+
+### 14. Promote and Sign the Release Builds
 
 **The same individual who signed the release tag must be the one
 to promote the builds as the `SHASUMS256.txt` file needs to be signed with the
@@ -620,7 +622,7 @@ be prompted to re-sign `SHASUMS256.txt`.
 **It is possible to only sign a release by running `./tools/release.sh -s
 vX.Y.Z`.**
 
-### 14. Check the Release
+### 15. Check the Release
 
 Your release should be available at `https://nodejs.org/dist/vx.y.z/` and
 <https://nodejs.org/dist/latest/>. Check that the appropriate files are in
@@ -629,7 +631,7 @@ have the right internal version strings. Check that the API docs are available
 at <https://nodejs.org/api/>. Check that the release catalog files are correct
 at <https://nodejs.org/dist/index.tab> and <https://nodejs.org/dist/index.json>.
 
-### 15. Create a Blog Post
+### 16. Create a Blog Post
 
 There is an automatic build that is kicked off when you promote new builds, so
 within a few minutes nodejs.org will be listing your new version as the latest
@@ -662,7 +664,7 @@ This script will use the promoted builds and changelog to generate the post. Run
 * Changes to `master` on the [nodejs.org repository][] will trigger a new build
   of nodejs.org so your changes should appear a few minutes after pushing.
 
-### 16. Create the release on GitHub
+### 17. Create the release on GitHub
 
 * Go to the [New release page](https://github.com/nodejs/node/releases/new).
 * Select the tag version you pushed earlier.
@@ -670,11 +672,11 @@ This script will use the promoted builds and changelog to generate the post. Run
 * For the description, copy the rest of the changelog entry.
 * Click on the "Publish release" button.
 
-### 17. Cleanup
+### 18. Cleanup
 
 Close your release proposal PR and delete the proposal branch.
 
-### 18. Announce
+### 19. Announce
 
 The nodejs.org website will automatically rebuild and include the new version.
 To announce the build on Twitter through the official @nodejs account, email
@@ -691,7 +693,7 @@ announcements.
 
 Ping the IRC ops and the other [Partner Communities][] liaisons.
 
-### 19. Celebrate
+### 20. Celebrate
 
 _In whatever form you do this..._