diff --git a/README.md b/README.md
index ff5f24d..59ae76a 100644
--- a/README.md
+++ b/README.md
@@ -8,14 +8,14 @@
   <a href="https://pypi.org/project/nautobot-capacity-metrics/"><img src="https://img.shields.io/pypi/v/nautobot-capacity-metrics"></a>
   <a href="https://pypi.org/project/nautobot-capacity-metrics/"><img src="https://img.shields.io/pypi/dm/nautobot-capacity-metrics"></a>
   <br>
-  An <a href="https://www.networktocode.com/nautobot/apps/">App</a> for <a href="https://nautobot.com/">Nautobot that exposes additional metrics information</a>.
+  An <a href="https://www.networktocode.com/nautobot/apps/">App</a> for <a href="https://nautobot.com/">Nautobot</a> that exposes additional metrics information.
 </p>
 
 ## Metrics Endpoints
 
 Nautobot already exposes some information via a Prometheus endpoint but the information currently available are mostly at the system level and not at the application level. System metrics and application level metrics are complementary with each other.
 
-- **SYSTEM Metrics** are very useful to instrument code, track ephemeral information and get a better visibility into what is happening. (Example of metrics: nbr of requests, requests per second, nbr of exceptions, response time, etc ...) The idea is that when multiple instances of Nautobot are running behind a load balancer each one will produce a different set of metrics and the monitoring system needs to collect these metrics from all running instances and aggregate them in a dashboard. Nautobot exposes some system metrics at `localhost/metrics` [Nautobot DOC](https://nautobot.readthedocs.io/en/stable/additional-features/prometheus-metrics/).
+- **SYSTEM Metrics** are very useful to instrument code, track ephemeral information and get a better visibility into what is happening. (Example of metrics: nbr of requests, requests per second, nbr of exceptions, response time, etc ...) The idea is that when multiple instances of Nautobot are running behind a load balancer each one will produce a different set of metrics and the monitoring system needs to collect these metrics from all running instances and aggregate them in a dashboard. Nautobot exposes some system metrics at `localhost/metrics` - read more in the [Nautobot Documentation](https://docs.nautobot.com/projects/core/en/stable/user-guide/administration/guides/prometheus-metrics/).
 - **APPLICATION Metrics** are at a higher level and represent information that is the same across all instances of an application running behind a load balancer. If I have 3 instances of Nautobot running, there is no point to ask each of them how many Device objects I have in the database, since they will always return the same information. In this case, the goal is to expose only 1 endpoint that can be served by any running instance. The prometheus endpoint is at `/api/plugins/capacity-metrics/app-metrics`.
 
 Currently the app exposes these simple metrics by default:
diff --git a/docs/user/faq.md b/docs/user/faq.md
index 4b4efe5..c9a68d0 100644
--- a/docs/user/faq.md
+++ b/docs/user/faq.md
@@ -2,19 +2,19 @@
 
 ## Nautobot already exposes a metrics endpoint, why do I need another one?
 
-> System metrics and application level metrics are complementary with each other:
->
-> - **SYSTEM Metrics** are very useful to instrument code, track ephemeral information and get a better visibility into what is happening. (Example of metrics: nbr of requests, requests per second, nbr of exceptions, response time, etc ...) The idea is that if we have multiple Nautobot instances running behind a load balancer each one will produce a different set of metrics and the monitoring system needs to collect these metrics from all running instances and aggregate them in a dashboard. Nautobot exposes some system metrics by default at `localhost/metrics`.
-> - **APPLICATION Metrics** are at a higher level and represent information that is the same across all instances of an application running behind a load balancer. if I have 3 instances of Nautobot running, there is no point to ask each of them how many Device objects I have in the database, since they will always return the same information. In this case, the goal is to expose only 1 endpoint that can be served by any running instance.
+System metrics and application level metrics are complementary with each other:
+
+- **SYSTEM Metrics** are very useful to instrument code, track ephemeral information and get a better visibility into what is happening. (Example of metrics: nbr of requests, requests per second, nbr of exceptions, response time, etc ...) The idea is that if we have multiple Nautobot instances running behind a load balancer each one will produce a different set of metrics and the monitoring system needs to collect these metrics from all running instances and aggregate them in a dashboard. Nautobot exposes some system metrics by default at `localhost/metrics`.
+- **APPLICATION Metrics** are at a higher level and represent information that is the same across all instances of an application running behind a load balancer. if I have 3 instances of Nautobot running, there is no point to ask each of them how many Device objects I have in the database, since they will always return the same information. In this case, the goal is to expose only 1 endpoint that can be served by any running instance.
 
 ## Do I need an API token to access the application metrics endpoint? 
 
-> No, currently no authentication is required (or possible).
+No, currently no authentication is required (or possible).
 
 ## I don't see the plugin in the API documentation, is it expected?
 
-> Yes, this is expected. This API endpoint is not published in the swagger documentation because it's not a REST compatible endpoint.
+Yes, this is expected. This API endpoint is not published in the swagger documentation because it's not a REST compatible endpoint.
 
 ## Does this plugin support Nautobot 2.0?
 
-> Yes
+Yes