diff --git a/content/docs/BestPractices/CustomTelemetry/index.md b/content/docs/BestPractices/CustomTelemetry/index.md
index 9f8b7ba0..c2f1eb20 100644
--- a/content/docs/BestPractices/CustomTelemetry/index.md
+++ b/content/docs/BestPractices/CustomTelemetry/index.md
@@ -71,7 +71,7 @@ Of course it is possible to have a single object as a central place to emit tele
 
 ## Candidate data for telemetry
 
-Telemetry must be **actionable** for the customer. Do not emit signals that they cannot act on (knowing about CPU performance counters on the database is useless if the partner cannot scale the database)
+Telemetry must be **actionable** for the customer. Do not emit signals that they cannot act on (knowing about CPU performance counters on the database is useless if the partner cannot scale the database).
 
 Also, note that customers pay for data ingestion. So be mindful to not flood their telemetry resources. Consider to use TelemetryScope::ExtensionPublisher by default and only use TelemetryScope::All in case the customer can also act on the data.
 
diff --git a/content/docs/BestPractices/api-page/index.md b/content/docs/BestPractices/api-page/index.md
index b2d38d46..b541fe10 100644
--- a/content/docs/BestPractices/api-page/index.md
+++ b/content/docs/BestPractices/api-page/index.md
@@ -166,7 +166,7 @@ It is common use to give certain fields a more describing name. Some examples ar
 These fields should always be part of the API Page:
 
 * SystemId
-  * This field should be exposed wit the name ```id```  
+  * This field should be exposed with the name ```id```
 * SystemModifiedAt
   * This field should be exposed with the name ```lastModifiedDateTime```. If you choose a different name, then the webhook functionality will not work properly.