Grammar in Running section

docs/run-platform-server/running.mdx

@@ -9,13 +9,13 @@ Once you have [established the Horizon database](./configuring.mdx#initialize-ho
 
 If you chose bare metal installation, run the `stellar-horizon` binary with the [appropriate environment parameters](./configuring.mdx#parameters) set (or `stellar-horizon-cmd serve` if you [installed via the package manager](./installing.mdx#package-manager), which will automatically import your configuration from `/etc/default/stellar-horizon`).
 
-If you chose containerized installation, you don't execute the horizon binary directly, instead the [stellar/stellar-horizon](https://hub.docker.com/r/stellar/stellar-horizon) image has a pre-defined entrypoint that will start running horizon at image startup time. The horizon process will get all configuration settings from container environment variables.
+If you chose containerized installation, you don't execute the Horizon binary directly, instead the [stellar/stellar-horizon](https://hub.docker.com/r/stellar/stellar-horizon) image has a pre-defined entrypoint that will start running Horizon at image startup time. The Horizon process will get all configuration settings from container environment variables.
 
-- To run the image as a container on docker daemon of host, use `docker run stellar/stellar-horizon:<tag_version> --env-file <env_filename>`, and specify each horizon configuration flag identified during [Configuring](./configuring.mdx) as separate line in `<env_filename>` of `HORIZON_CONFIG_PARAM=value`.
+- To run the image as a container on Docker daemon of host, use `docker run stellar/stellar-horizon:<tag_version> --env-file <env_filename>`, and specify each Horizon configuration flag identified during [Configuring](./configuring.mdx) as a separate line in `<env_filename>` of `HORIZON_CONFIG_PARAM=value`.
 
-- To run on Kubernetes using helm chart, ensure you have followed the [pre-requisite](./installing.mdx#helm-chart-installation) of installing the Helm cli tool and adding the Stellar chart repo to helm client:
+- To run on Kubernetes using Helm Chart, ensure you have followed the [pre-requisite](./installing.mdx#helm-chart-installation) of installing the Helm CLI tool and added the Stellar chart repo to Helm client:
 
-  The horizon process [requires access to a Postgres 12 database](./configuring.mdx#preparing-the-database). First use the common kubernetes cli tool `kubectl` from your workstation to create a kubernetes secret on the intended namespace of the kubernetes cluster which will hold the horizon database url.
+  The Horizon process [requires access to a Postgres 12 database](./configuring.mdx#preparing-the-database). First use the common Kubernetes CLI tool `kubectl` from your workstation to create a Kubernetes secret on the intended namespace of the Kubernetes cluster which will hold the Horizon database URL.
 
   <CodeExample>
 
@@ -32,7 +32,7 @@ If you chose containerized installation, you don't execute the horizon binary di
 
   </CodeExample>
 
-  Now deploy horizon onto the cluster using the helm chart:
+  Now deploy Horizon onto the cluster using the Helm Chart:
 
   <CodeExample>
 
@@ -55,12 +55,12 @@ If you chose containerized installation, you don't execute the horizon binary di
 
   </CodeExample>
 
-  This example of helm chart usage, highlights some key aspects:
+  This example of Helm Chart usage highlights some key aspects:
 
-  - uses the `global.network=[testnet|pubnet]` parameter, this automates generation of all the horizon configuration parameters specific to network such as archive urls, captive core config, etc and other parameters as mentioned on [Configuring](./configuring.mdx).
-  - `global.image.horizon.tag` should be set to one of docker hub tags published on [stellar/stellar-horizon](https://hub.docker.com/r/stellar/stellar-horizon)
-  - enables all roles on the deployment instance: ingesting, and web api(includes transaction submission). If you choose to have a multi-instance deployment with each instance performing a single role of just web api or ingestion, then you will do two helm installations, one for each role: `my-horizon-ingestion-installation` and `my-horizon-api-installation`. Each of these helm installations will set `ingest.enabled`, `web.enabled`, `ingest.replicaCount`, `web.replicaCount` respectively for the role they are performing.
-  - to customize further, the best approach is to download the [horizon helm chart values.yaml](https://github.com/stellar/helm-charts/blob/main/charts/horizon/values.yaml), update the settings in your local copy of values.yaml, and pass to helm install, rather than have many individual `--set` on helm install:
+  - Uses the `global.network=[testnet|pubnet]` parameter, this automates generation of all the Horizon configuration parameters specific to the network such as archive urls, captive core config, and other parameters mentioned in [Configuring](./configuring.mdx).
+  - `global.image.horizon.tag` should be set to one of the Docker Hub tags published on [stellar/stellar-horizon](https://hub.docker.com/r/stellar/stellar-horizon)
+  - Enables all roles on the deployment instance: ingesting and web API (includes transaction submission). If you choose to have a multi-instance deployment with each instance performing a single role of just web API or ingestion, then you will do two Helm installations, one for each role: `my-horizon-ingestion-installation` and `my-horizon-api-installation`. Each of these Helm installations will set `ingest.enabled`, `web.enabled`, `ingest.replicaCount`, `web.replicaCount` respectively for the role they are performing.
+  - To customize further, the best approach is to download the [Horizon Helm Chart values.yaml](https://github.com/stellar/helm-charts/blob/main/charts/horizon/values.yaml), update the settings in your local copy of values.yaml, and pass to Helm install, rather than have many individual `--set` on Helm install:
 
     <CodeExample>
 
@@ -72,13 +72,13 @@ If you chose containerized installation, you don't execute the horizon binary di
 
     </CodeExample>
 
-  - specific to customizing network configuration parameters, if you want to connect to a network other than presets of `testnet` or `pubnet`, then you won't use `global.network`, instead, use local copy of [values.yaml](https://github.com/stellar/helm-charts/blob/main/charts/horizon/values.yaml) and set `ingest.coreConfig`, and refer to [\_core-config.tpl](https://github.com/stellar/helm-charts/blob/main/charts/horizon/templates/_core-config.tpl) for example of all the key/value pairs to include.
+  - Specific to customizing network configuration parameters, if you want to connect to a network other than presets of `testnet` or `pubnet`, then you won't use `global.network`, instead, use local copy of [values.yaml](https://github.com/stellar/helm-charts/blob/main/charts/horizon/values.yaml) and set `ingest.coreConfig`, and refer to [\_core-config.tpl](https://github.com/stellar/helm-charts/blob/main/charts/horizon/templates/_core-config.tpl) for example of all the key/value pairs to include.
 
-  - minimum resource limits, verify whether `LimitRange` defaults are defined on the target namespace in kubernetes for deployment, if so, ensure that the defaults provide at least minimum resource limits of `6Gi` of memory and `1` cpu. Otherwise, define the limits explicitly on the helm install via the `ingest.resources.limits.*` shown in example, to ensure the deployed pods have adequate resources.
+  - Minimum resource limits, verify whether `LimitRange` defaults are defined on the target namespace in Kubernetes for deployment, if so, ensure that the defaults provide at least minimum resource limits of `6Gi` of memory and `1` cpu. Otherwise, define the limits explicitly on the helm install via the `ingest.resources.limits.*` shown in example, to ensure the deployed pods have adequate resources.
 
 <br />
 
-Once the horizon process starts it will emit logging to standard out. When run, you should see output similar to:
+Once the Horizon process starts, it will emit logging to standard out. When run, you should see output similar to:
 
 <CodeExample>
 
@@ -112,4 +112,4 @@ Next, you can confirm that Horizon is responding correctly by loading the root r
 
 </CodeExample>
 
-Refer to [Monitoring](./monitoring.mdx) for more details on horizon runtime logging and metrics available.
+Refer to [Monitoring](./monitoring.mdx) for more details on Horizon runtime logging and metrics available.