address comments

site/content/how-to/monitoring/troubleshooting.md

@@ -78,7 +78,7 @@ kubectl exec -it -n nginx-gateway  <ngf-pod-name> -c nginx /bin/sh
 
 #### Logs
 
-Logs from the NGINX Gateway Fabric control plane and data plane can contain information that isn't available to status or events. These can include errors in processing or passing traffic.
+Logs from the NGINX Gateway Fabric control plane and data plane can contain information that isn't available to status or events. These can include errors in processing or passing traffic. You can see logs for a crashed or killed container by adding the `-p` flag to the above commands.
 
 1. Container Logs
 
@@ -96,9 +96,7 @@ Logs from the NGINX Gateway Fabric control plane and data plane can contain info
 
 1. Error Logs
 
-    To see error logs for control plane and data plane containers:
-
-    For _nginx-gateway_ container, you can `grep` for the word `error` or change the log level to `error` by following steps in Modify log levels (Section 3). Once you have modified log levels, you can `grep` for the word `debug` to check debug logs for further investigation.
+    For _nginx-gateway_ container, you can `grep` for the word `error` or change the log level to `error` by following steps in Modify log levels (Section 4).
 
     ```shell
     kubectl -n nginx-gateway logs <ngf-pod-name> -c nginx-gateway | grep error
@@ -130,12 +128,15 @@ Logs from the NGINX Gateway Fabric control plane and data plane can contain info
     NGINX access logs record all requests processed by the NGINX server. These logs provide detailed information about each request, which can be useful for troubleshooting and analyzing web traffic.
     Access logs can be viewed with the above method of using `kubectl logs`, or by viewing the access log file directly. To do that, get shell access to your NGINX container using these [steps](#get-shell-access-to-nginx-container). The access logs are located in the file `/var/log/nginx/access.log` in the NGINX container.
 
-    You can see logs for a crashed or killed container by adding the `-p` flag to the above commands.
-
 1. Modify Log Levels
 
     To see debug logs for control plane in NGINX Gateway Fabric, enable verbose logging by editing the `NginxGateway` configuration. This can be done either before or after deploying NGINX Gateway Fabric. Refer to this [guide](https://docs.nginx.com/nginx-gateway-fabric/how-to/configuration/control-plane-configuration) to do so.
 
+1. Debug Logs
+
+    Once you have modified log levels for NGINX Gateway Fabric, you can `grep` for the word `debug` to check debug logs for further investigation.
+
+
 #### Understanding the generated NGINX config
 
 Understanding the NGINX configuration is key for fixing issues because it shows how NGINX handles requests. This helps tweak settings to make sure NGINX behaves the way you want it to for your application. To see your current configuration, you can open a shell in the _nginx_ container by following these [steps](#get-shell-access-to-nginx-container) and run `nginx -T`. To understand the usage of NGINX directives in the configuration file, consult this list of [NGINX directives](https://nginx.org/en/docs/dirindex.html).
@@ -156,7 +157,7 @@ server {
 
 Once a HTTPRoute with path matches and rules are defined, the nginx.conf is updated accordingly to determine which location block will manage incoming requests. To demonstrate how `nginx.conf` is changed, let's create some resources:
 
-1. A Gateway with single listener with the hostname `*.example.com` on port 80. 
+1. A Gateway with single listener with the hostname `*.example.com` on port 80.
 2. A simple `coffee` application.
 3. An HTTPRoute that exposes the `coffee` application outside the cluster using the listener created in step 1. The path and rule matches create different location blocks in `nginx.conf` to route requests as needed.
 
@@ -314,7 +315,7 @@ To debug why your reload has failed, start with verifying the syntax of your con
 
 ##### NGINX Gateway Fabric Pod is not running or ready
 
-To understand why the NGINX Gateway Fabric Pod has not started running or is not ready, the first step is to check the state of the Pod to get detailed information about the current status and events happening in the Pod. To do this, use `kubectl describe`:
+To understand why the NGINX Gateway Fabric Pod has not started running or is not ready, check the state of the Pod to get detailed information about the current status and events happening in the Pod. To do this, use `kubectl describe`:
 
 ```shell
 kubectl describe pod <ngf-pod-name> -n nginx-gateway