diff --git a/docs/setup/install/install-devtron-helm-2.md b/docs/setup/install/install-devtron-helm-2.md
index fd0c62f418..cb402d6f94 100644
--- a/docs/setup/install/install-devtron-helm-2.md
+++ b/docs/setup/install/install-devtron-helm-2.md
@@ -70,6 +70,11 @@ kubectl -n devtroncd get installers installer-devtron -o jsonpath='{.status.sync
 ```
 
 The install commands initiates Devtron-operator which spins up all the Devtron micro-services one by one in about 20 mins. You can use the above command to check the status of the installation if the installation is still in progress, it will print `Downloaded`. When the installation is complete, it prints `Applied`.
+Meanwhile, you can check logs of the installer by executing the following command:
+
+```bash
+kubectl logs -f -l app=inception -n devtroncd
+```
 
 ## Access Devtron dashboard
 
diff --git a/docs/setup/install/install-devtron-helm-3.md b/docs/setup/install/install-devtron-helm-3.md
index ada205fbbf..cce1c1872b 100644
--- a/docs/setup/install/install-devtron-helm-3.md
+++ b/docs/setup/install/install-devtron-helm-3.md
@@ -63,6 +63,11 @@ kubectl -n devtroncd get installers installer-devtron -o jsonpath='{.status.sync
 ```
 
 The install commands initiates Devtron-operator which spins up all the Devtron micro-services one by one in about 20 mins. You can use the above command to check the status of the installation if the installation is still in progress, it will print `Downloaded`. When the installation is complete, it prints `Applied`.
+Meanwhile, you can check logs of the installer by executing the following command:
+
+```bash
+kubectl logs -f -l app=inception -n devtroncd
+```
 
 ## Access Devtron dashboard
 
diff --git a/docs/setup/install/install-devtron-using-kubectl.md b/docs/setup/install/install-devtron-using-kubectl.md
index c0302563ed..2c253afb7c 100644
--- a/docs/setup/install/install-devtron-using-kubectl.md
+++ b/docs/setup/install/install-devtron-using-kubectl.md
@@ -35,7 +35,11 @@ kubectl -n devtroncd get installers installer-devtron -o jsonpath='{.status.sync
 ```
 
 The install commands initiates Devtron-operator which spins up all the Devtron micro-services one by one in about 20 mins. You can use the above command to check the status of the installation if the installation is still in progress, it will print `Downloaded`. When the installation is complete, it prints `Applied`.
+Meanwhile, you can check logs of the installer by executing the following command:
 
+```bash
+kubectl logs -f -l app=inception -n devtroncd
+```
 ## Access Devtron dashboard
 
 If you did not provide a **BASE\_URL** during install or have used the default installation, Devtron creates a loadbalancer for you on its own. Use the following command to get the dashboard url.
diff --git a/docs/user-guide/creating-application/deployment-template/rollout-deployment.md b/docs/user-guide/creating-application/deployment-template/rollout-deployment.md
index bb5a25bb2d..3d5be5472a 100644
--- a/docs/user-guide/creating-application/deployment-template/rollout-deployment.md
+++ b/docs/user-guide/creating-application/deployment-template/rollout-deployment.md
@@ -71,6 +71,9 @@ LivenessProbe:
   successThreshold: 1
   timeoutSeconds: 5
   failureThreshold: 3
+  command:
+    - python
+    - /etc/app/healthcheck.py
   httpHeaders:
     - name: Custom-Header
       value: abc
@@ -86,6 +89,7 @@ LivenessProbe:
 | `successThreshold` | It defines the number of successes required before a given container is said to fulfil the liveness probe. |
 | `timeoutSeconds` | It defines the time for checking timeout. |
 | `failureThreshold` | It defines the maximum number of failures that are acceptable before a given container is not considered as live. |
+| `command` | The mentioned command is executed to perform the livenessProbe. If the command returns a non-zero value, it's equivalent to a failed probe. |
 | `httpHeaders` | Custom headers to set in the request. HTTP allows repeated headers,You can override the default headers by defining .httpHeaders for the probe. |
 | `scheme` | Scheme to use for connecting to the host (HTTP or HTTPS). Defaults to HTTP.
 | `tcp` | The kubelet will attempt to open a socket to your container on the specified port. If it can establish a connection, the container is considered healthy. |
@@ -126,6 +130,9 @@ ReadinessProbe:
   successThreshold: 1
   timeoutSeconds: 5
   failureThreshold: 3
+  command:
+    - python
+    - /etc/app/healthcheck.py
   httpHeaders:
     - name: Custom-Header
       value: abc
@@ -141,6 +148,7 @@ ReadinessProbe:
 | `successThreshold` | It defines the number of successes required before a given container is said to fulfill the readiness probe. |
 | `timeoutSeconds` | It defines the time for checking timeout. |
 | `failureThreshold` | It defines the maximum number of failures that are acceptable before a given container is not considered as ready. |
+| `command` | The mentioned command is executed to perform the readinessProbe. If the command returns a non-zero value, it's equivalent to a failed probe. |
 | `httpHeaders` | Custom headers to set in the request. HTTP allows repeated headers,You can override the default headers by defining .httpHeaders for the probe. |
 | `scheme` | Scheme to use for connecting to the host (HTTP or HTTPS). Defaults to HTTP.
 | `tcp` | The kubelet will attempt to open a socket to your container on the specified port. If it can establish a connection, the container is considered healthy. |
@@ -206,9 +214,11 @@ ingress:
   annotations: {}
   hosts:
       - host: example1.com
+        pathType: "ImplementationSpecific"
         paths:
             - /example
       - host: example2.com
+        pathType: "ImplementationSpecific"
         paths:
             - /example2
             - /example2/healthz
@@ -231,8 +241,9 @@ ingress:
 | :--- | :--- |
 | `enabled` | Enable or disable ingress |
 | `annotations` | To configure some options depending on the Ingress controller |
-| `path` | Path name |
 | `host` | Host name |
+| `pathType` | Path in an Ingress is required to have a corresponding path type. Supported path types are `ImplementationSpecific`, `Exact` and `Prefix`. |
+| `path` | Path name |
 | `tls` | It contains security details |
 
 ### Ingress Internal
@@ -247,9 +258,11 @@ ingressInternal:
   annotations: {}
   hosts:
       - host: example1.com
+        pathType: "ImplementationSpecific"
         paths:
             - /example
       - host: example2.com
+        pathType: "ImplementationSpecific"
         paths:
             - /example2
             - /example2/healthz
@@ -260,8 +273,10 @@ ingressInternal:
 | :--- | :--- |
 | `enabled` | Enable or disable ingress |
 | `annotations` | To configure some options depending on the Ingress controller |
-| `path` | Path name |
 | `host` | Host name |
+| `pathType` | Path in an Ingress is required to have a corresponding path type. Supported path types are `ImplementationSpecific`, `Exact` and `Prefix`. |
+| `path` | Path name |
+| `pathType` | Supported path types are `ImplementationSpecific`, `Exact` and `Prefix`.|
 | `tls` | It contains security details |
 
 ### Init Containers