1 files changed, 11 insertions, 11 deletions
diff --git a/doc/administration/packages/container_registry.md b/doc/administration/packages/container_registry.md
index 541bd99084c..a9ec2764b80 100644
--- a/doc/administration/packages/container_registry.md
+++ b/doc/administration/packages/container_registry.md
@@ -820,7 +820,7 @@ If you did not change the default location of the configuration file, run:
 sudo gitlab-ctl registry-garbage-collect
 ```
 
-This command will take some time to complete, depending on the amount of
+This command takes some time to complete, depending on the amount of
 layers you have stored.
 
 If you changed the location of the Container Registry `config.yml`:
@@ -867,7 +867,7 @@ You can perform garbage collection without stopping the Container Registry by pu
 it in read-only mode and by not using the built-in command. On large instances
 this could require Container Registry to be in read-only mode for a while.
 During this time,
-you will be able to pull from the Container Registry, but you will not be able to
+you are able to pull from the Container Registry, but you are not able to
 push.
 
 By default, the [registry storage path](#configure-storage-for-the-container-registry)
@@ -896,7 +896,7 @@ To enable the read-only mode:
    sudo gitlab-ctl reconfigure
    ```
 
-   This will set the Container Registry into the read only mode.
+   This command sets the Container Registry into the read only mode.
 
 1. Next, trigger one of the garbage collect commands:
 
@@ -908,7 +908,7 @@ To enable the read-only mode:
    sudo /opt/gitlab/embedded/bin/registry garbage-collect -m /var/opt/gitlab/registry/config.yml
    ```
 
-   This will start the garbage collection, which might take some time to complete.
+   This command starts the garbage collection, which might take some time to complete.
 
 1. Once done, in `/etc/gitlab/gitlab.rb` change it back to read-write mode:
 
@@ -935,7 +935,7 @@ To enable the read-only mode:
 
 Ideally, you want to run the garbage collection of the registry regularly on a
 weekly basis at a time when the registry is not being in-use.
-The simplest way is to add a new crontab job that it will run periodically
+The simplest way is to add a new crontab job that it runs periodically
 once a week.
 
 Create a file under `/etc/cron.d/registry-garbage-collect`:
@@ -1155,7 +1155,7 @@ curl localhost:5001/debug/vars
 
 ### Advanced Troubleshooting
 
-We will use a concrete example in the past to illustrate how to
+We use a concrete example to illustrate how to
 diagnose a problem with the S3 setup.
 
 #### Unexpected 403 error during push
@@ -1227,14 +1227,14 @@ To verify that the certificates are properly installed, run:
 mitmproxy --port 9000
 ```
 
-This will run mitmproxy on port `9000`. In another window, run:
+This command runs mitmproxy on port `9000`. In another window, run:
 
 ```shell
 curl --proxy http://localhost:9000 https://httpbin.org/status/200
 ```
 
-If everything is set up correctly, you will see information on the mitmproxy window and
-no errors from the curl commands.
+If everything is set up correctly, information is displayed on the mitmproxy window and
+no errors are generated by the curl commands.
 
 #### Running the Docker daemon with a proxy
 
@@ -1248,7 +1248,7 @@ export HTTPS_PROXY="https://localhost:9000"
 docker daemon --debug
 ```
 
-This will launch the Docker daemon and proxy all connections through mitmproxy.
+This command launches the Docker daemon and proxies all connections through mitmproxy.
 
 #### Running the Docker client
 
@@ -1273,4 +1273,4 @@ The above image shows:
 What does this mean? This strongly suggests that the S3 user does not have the right
 [permissions to perform a HEAD request](https://docs.aws.amazon.com/AmazonS3/latest/API/API_HeadObject.html).
 The solution: check the [IAM permissions again](https://docs.docker.com/registry/storage-drivers/s3/).
-Once the right permissions were set, the error will go away.
+Once the right permissions were set, the error goes away.