diff --git a/apps/docs/content/troubleshooting/using-google-smtp-with-supabase-custom-smtp-ZZzU4Y.mdx b/apps/docs/content/troubleshooting/using-google-smtp-with-supabase-custom-smtp-ZZzU4Y.mdx
index 588b6ff151..a748c11619 100644
--- a/apps/docs/content/troubleshooting/using-google-smtp-with-supabase-custom-smtp-ZZzU4Y.mdx
+++ b/apps/docs/content/troubleshooting/using-google-smtp-with-supabase-custom-smtp-ZZzU4Y.mdx
@@ -10,7 +10,7 @@ database_id = "4d5390a0-445d-4e0a-ae7e-9b713b7cc4f6"
 Hey everyone, i've been hearing feedback about how challenging it can be to get google SMTP working properly with Supabase. I've tried setting this up with a trial google workspace account and this is what i've discovered.
 
 1. The sender email and SMTP username has to be your google workspace admin email.
-2. The SMTP password used has to be an app password. Google workspace doesn't make it easy to to figure out how to create this. You need to **enable 2FA** on your workspace account first (not inside the admin console but in https://myaccount.google.com/)
+2. The SMTP password used has to be an app password. Google workspace doesn't make it easy to figure out how to create this. You need to **enable 2FA** on your workspace account first (not inside the admin console but in https://myaccount.google.com/)
 3. If you want to use `smtp-relay.gmail.com` only port 465 works. If you want to use `smtp.gmail.com`, you can use port 465 or 587.
    The following screenshots show what those steps look like:
 
diff --git a/apps/docs/content/troubleshooting/why-is-my-service-role-key-client-getting-rls-errors-or-not-returning-data-7_1K9z.mdx b/apps/docs/content/troubleshooting/why-is-my-service-role-key-client-getting-rls-errors-or-not-returning-data-7_1K9z.mdx
index a07684797a..3bf968d6cd 100644
--- a/apps/docs/content/troubleshooting/why-is-my-service-role-key-client-getting-rls-errors-or-not-returning-data-7_1K9z.mdx
+++ b/apps/docs/content/troubleshooting/why-is-my-service-role-key-client-getting-rls-errors-or-not-returning-data-7_1K9z.mdx
@@ -22,6 +22,6 @@ Three common cases of the `createClient` `apikey` being replaced by a user sessi
 
 2. Edge functions or other server code setting the `Authorization` header in `createClient` options directly to a user token/JWT. When you set the `Authorization` header directly that overrides the default action of using the `apikey` for the `Authorization` header.
 
-3. Server client initialized with service role using `signUp` to create a user or other auth functions. Many auth functions will return a user session to the client making the call. When that happens the `apikey` will be replaced by the user token/JWT in the `Authorization` header. If you are wanting to create a user in a service role client use `admin.createUser()` instead. Otherwise use a separate Supabase client for for service role from other actions.
+3. Server client initialized with service role using `signUp` to create a user or other auth functions. Many auth functions will return a user session to the client making the call. When that happens the `apikey` will be replaced by the user token/JWT in the `Authorization` header. If you are wanting to create a user in a service role client use `admin.createUser()` instead. Otherwise use a separate Supabase client for service role from other actions.
 
 Also note that adding `service_role` in RLS policies does nothing. Service role will never run the policies to begin with.