fix/docs: fix spelling errors

docs/admin/auth/index.mdx

@@ -143,7 +143,7 @@ The new user email, during their account creation, should match one of their Git
 
 Restricts sign-ins to members of the listed organizations. If empty or unset, no restriction will be applied.
 
-If combined with `"allowSignup": true`, only members of the allowed orgs can create their accounts in Sourcegraph via GitHub authentitcation.
+If combined with `"allowSignup": true`, only members of the allowed orgs can create their accounts in Sourcegraph via GitHub authentication.
 
 When combined with `"allowSignup": false` or unset, an admin should first create the user account so that the user can sign in with GitHub if they belong to the allowed orgs.
 
@@ -284,7 +284,7 @@ When empty or unset, no restrictions will be applied.
 
 If combined with `"allowSignup": false`, an admin should first create the user account so that the user can sign in with GitLab.
 
-If combined with `"allowSignup": true` or with `allowSignup` unset, only members of the allowed groups or subgroups can create their accounts in Sourcegraph via GitLab authentitcation.
+If combined with `"allowSignup": true` or with `allowSignup` unset, only members of the allowed groups or subgroups can create their accounts in Sourcegraph via GitLab authentication.
 
 > WARNING: Users will require a minimum access level of `Guest` in at least one of the specified groups in order to gain access to Sourcegraph. GitLab offers a lower user permission level, [Minimal Access](https://docs.gitlab.com/ee/user/permissions.html#users-with-minimal-access), for Premium and Ultimate tier customers, which is often used to configure SAML SSO on GitLab. Sourcegraph does not currently support the `Minimal Access` access level, and users with this access level will not be allowed to sign in. In these cases it is recommended to create a subgroup and add all users that require access to Sourcegraph to that subgroup with a minimum access level of `Guest`, and then add that subgroup to the `allowGroups` list.
 

docs/admin/auth/saml/okta.mdx

@@ -31,7 +31,7 @@
     - Copy the URL from the new browser tab that will open. It will have the following format:
 
     ```sh
-        https://<your tenant>.okta.com/app/<unique identitfier>/sso/saml/metadata
+        https://<your tenant>.okta.com/app/<unique identifier>/sso/saml/metadata
     ```
 
 ## 2. Add the SAML auth provider to Sourcegraph site config

docs/admin/code-hosts/gerrit.mdx

@@ -72,7 +72,7 @@ To clone using SSH, provide `"gitSSHCredential"` in the configuration:
 
 ## Add Gerrit as an authentication provider
 
-If the `"authorization": {}` option has been set on a Gerrit code host connection, a Gerrit authentication provider will be required so that authroized users are able to search for and browse the code mirrored by that code host connection.
+If the `"authorization": {}` option has been set on a Gerrit code host connection, a Gerrit authentication provider will be required so that authorized users are able to search for and browse the code mirrored by that code host connection.
 
 1. In the **Site Admin** settings area, select [**Site configuration**](/admin/config/site-config) from the options on the left.
 2. Add a Gerrit configuration to the list of `"auth.providers"`.

docs/admin/code-hosts/github.mdx

@@ -171,7 +171,7 @@ If you get an error message similar to following error while adding a GitHub App
 
 ```
 
-It means that the IP allowlist is enabled at the organisation level and you will need to add sourcegraph's IP addresseses to this allowlist in order for the app connection to work (see [GitHub's documentation](https://docs.github.com/en/enterprise-cloud@latest/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/managing-allowed-ip-addresses-for-your-organization#adding-an-allowed-ip-address))
+It means that the IP allowlist is enabled at the organisation level and you will need to add Sourcegraph's IP addresses to this allowlist in order for the app connection to work (see [GitHub's documentation](https://docs.github.com/en/enterprise-cloud@latest/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/managing-allowed-ip-addresses-for-your-organization#adding-an-allowed-ip-address))
 
 ### Uninstalling an App
 

docs/admin/code-hosts/src-serve-git.mdx

@@ -23,7 +23,7 @@ The most common use-case for `src serve-git` is to create git repos that do not
 -   Using `git p4` to serve up Perforce repositories.
 -   Serve up local repositories to Sourcegraph while trialling it.
 
-> WARNING: `src serve-git` is not intended to be used to serve repos from a code host which is already configured to be synced by a seperate code host config. For instance if you have a self managed GitLab code host, it is not advised to use `src serve-git` to serve repos on the gitlab server.
+> WARNING: `src serve-git` is not intended to be used to serve repos from a code host which is already configured to be synced by a separate code host config. For instance if you have a self managed GitLab code host, it is not advised to use `src serve-git` to serve repos on the gitlab server.
 
 ## Quickstart
 

docs/admin/how-to/mutate-user-api.mdx

@@ -55,7 +55,7 @@ This query will return the username after altering the user's username data as s
 }
 ```
 
-Learn more about the options available with the `updateUser` query in the graphQL API consule Documentation Explorer.
+Learn more about the options available with the `updateUser` query in the graphQL API console Documentation Explorer.
 
 ## Remove a user
 

docs/admin/how-to/repo-not-updated.mdx

@@ -26,7 +26,7 @@ This document assumes that you are a [site admin](/admin) and **do not** have `d
 
 ### What is a bad repository?
 
-A bad repository is simiply a repository that Sourcegraph cannot handle. For example:
+A bad repository is simply a repository that Sourcegraph cannot handle. For example:
 
 1. A large repository
     - This could result in gitserver running out of memory.

docs/admin/how-to/site-admin-quickstart.mdx

@@ -14,7 +14,7 @@ If you need a deployment option that offers a higher level of scalability and av
 
 To help give you a starting point on choosing a deployment option and allocating resources to it, check out our [resource estimator](/self-hosted/deploy/resource-estimator).
 
-For a comphrensive deployment guide for each option, check out our in-depth documentation for both [Docker Compose](/self-hosted/deploy/docker-compose/) and [Kubernetes](/self-hosted/deploy/kubernetes/).
+For a comprehensive deployment guide for each option, check out our in-depth documentation for both [Docker Compose](/self-hosted/deploy/docker-compose/) and [Kubernetes](/self-hosted/deploy/kubernetes/).
 
 ### Deployment options
 

docs/admin/permissions/api.mdx

@@ -4,7 +4,7 @@ Sourcegraph's GraphQL API allows users to explicitly set repository permissions.
 
 ## Permissions mechanisms in parallel
 
-If you want to use explicit permissions managmeent alongside permissions synchronised from code hosts, read section [permission mechanisms in parallel here](/admin/permissions/#permissions-mechanisms-in-parallel).
+If you want to use explicit permissions management alongside permissions synchronised from code hosts, read section [permission mechanisms in parallel here](/admin/permissions/#permissions-mechanisms-in-parallel).
 
 ## Recommendations
 

docs/admin/scim.mdx

@@ -16,7 +16,7 @@ Sourcegraph supports SCIM 2.0 for provisioning and de-provisioning _users_.
 	SCIM integration requires your SCIM provider to have network connectivity to
 	your Sourcegraph instance. For example, using Okta's SCIM service with a
 	private Sourcegraph instance, you will need to implement an [Okta
-	privisioning
+	provisioning
 	agent](https://help.okta.com/en-us/content/topics/provisioning/opp/opp-main.htm)
 	within a network that can connect to both your Sourcegraph instance and
 	Okta's cloud services before continuing this setup.

docs/admin/telemetry/protocol.mdx

@@ -95,7 +95,7 @@ To learn more, refer to our [telemetry documentation](https://sourcegraph.com/do
 
 | Field | Type | Label | Description |
 | ----- | ---- | ----- | ----------- |
-| flags | [EventFeatureFlags.FlagsEntry](#telemetrygateway-v1-EventFeatureFlags-FlagsEntry) | repeated | <p>Evaluated feature flags. In Soucegraph we currently only support boolean</p><p>feature flags, but in the API we allow arbitrary string values for future</p><p>extensibility.</p><p>This field should be hydrated by the Sourcegraph server, and not provided</p><p>by clients.</p> |
+| flags | [EventFeatureFlags.FlagsEntry](#telemetrygateway-v1-EventFeatureFlags-FlagsEntry) | repeated | <p>Evaluated feature flags. In Sourcegraph we currently only support boolean</p><p>feature flags, but in the API we allow arbitrary string values for future</p><p>extensibility.</p><p>This field should be hydrated by the Sourcegraph server, and not provided</p><p>by clients.</p> |
 
 
 
@@ -619,17 +619,17 @@ Sourcegraph Analytics features.
  {/* end HasExtensions */}
 
 
-<a name="telemetrygateway-v1-TelemeteryGatewayService"></a>
+<a name="telemetrygateway-v1-TelemetryGatewayService"></a>
 
-### TelemeteryGatewayService
+### TelemetryGatewayService
 TelemetryGatewayService accepts telemetry and related data from Sourcegraph
 instances and managed services.
 
 | Method Name | Request Type | Response Type | Description |
 | ----------- | ------------ | ------------- | ------------|
 | RecordEvents | [RecordEventsRequest](#telemetrygateway-v1-RecordEventsRequest) stream | [RecordEventsResponse](#telemetrygateway-v1-RecordEventsResponse) stream | <p>RecordEvents streams telemetry events in batches to the Telemetry Gateway</p><p>service. Events should only be considered delivered if recording is</p><p>acknowledged in RecordEventsResponse.</p><p>This is the preferred mechanism for exporting large volumes of events in</p><p>bulk.</p><p>🚨 SECURITY: Callers exporting for single-tenant Sourcegraph should check</p><p>the attributes of the Event type to ensure that only the appropriate fields</p><p>are exported, as some fields should only be exported on an allowlist basis.</p> |
 | RecordEvent | [RecordEventRequest](#telemetrygateway-v1-RecordEventRequest) | [RecordEventResponse](#telemetrygateway-v1-RecordEventResponse) | <p>RecordEvent records a single telemetry event to the Telemetry Gateway service.</p><p>If the RPC succeeds, then the event was successfully published.</p><p>This RPC currently ONLY accepts events published by ManagedServiceIdentifier,</p><p>as this mechanism is intended for low-volume managed services. Higher-volume</p><p>use cases should implement a batching mechanism and use the RecordEvents</p><p>RPC instead.</p><p>🚨 SECURITY: Callers exporting for single-tenant Sourcegraph should check</p><p>the attributes of the Event type to ensure that only the appropriate fields</p><p>are exported, as some fields should only be exported on an allowlist basis.</p> |
-| PublishInstanceUserMetadata | [PublishInstanceUserMetadataRequest](#telemetrygateway-v1-PublishInstanceUserMetadataRequest) stream | [PublishInstanceUserMetadataResponse](#telemetrygateway-v1-PublishInstanceUserMetadataResponse) | <p>PublishInstanceUserMetadata uploads additional user metadata from a</p><p>Sourcegraph instance. This matadata is used to enrich recorded events with</p><p>attributes that are considered sensitive and thus not part of the RecordEvents</p><p>and RecordEvent RPCs.</p><p>🚨 SECURITY: Callers exporting for single-tenant Sourcegraph should always</p><p>respect in-instance toggles for what user metadata should be exported.</p> |
+| PublishInstanceUserMetadata | [PublishInstanceUserMetadataRequest](#telemetrygateway-v1-PublishInstanceUserMetadataRequest) stream | [PublishInstanceUserMetadataResponse](#telemetrygateway-v1-PublishInstanceUserMetadataResponse) | <p>PublishInstanceUserMetadata uploads additional user metadata from a</p><p>Sourcegraph instance. This metadata is used to enrich recorded events with</p><p>attributes that are considered sensitive and thus not part of the RecordEvents</p><p>and RecordEvent RPCs.</p><p>🚨 SECURITY: Callers exporting for single-tenant Sourcegraph should always</p><p>respect in-instance toggles for what user metadata should be exported.</p> |
 
  {/* end services */}
 

docs/admin/webhooks/outgoing.mdx

@@ -88,7 +88,7 @@ The changeset webhook event payload mirrors the [GraphQL API](/api/graphql/) `Ex
 	"created_at": "2023-03-19T05:41:24Z",
 	// The date and time when the batch change was last updated.
 	"title": "Hello World",
-	// The body of the changese (as Markdown).
+	// The body of the changeset (as Markdown).
 	"body": "My first batch change!",
 	// The username of the author of the changeset. Note that this is only available after the changeset has been published and is not available on some code hosts.
 	"author_name": "my-username",
@@ -110,7 +110,7 @@ The changeset webhook event payload mirrors the [GraphQL API](/api/graphql/) `Ex
 	"check_state": "PASSED",
 	// Any error that occurred when publishing or updating the changeset.
 	"error": null,
-	// Any error that occured during the last sync of the changeset by Sourcegraph.
+	// Any error that occurred during the last sync of the changeset by Sourcegraph.
 	"syncer_error": null,
 	// The ID of the batch change that produced this changeset.
 	"owning_batch_change_id": "QmF0Y2hDaGFuZ2U6MTcz"

docs/api/index.mdx

@@ -16,7 +16,7 @@ For specific types of integrations, Sourcegraph also offers the following APIs:
 - [Sourcegraph Analytics API](/analytics/api/), for accessing your Sourcegraph Analytics data
 - [Webhooks](/admin/webhooks/), for receiving event notifications from Sourcegraph
 
-For diagnostics use cases, the [Sourcegraph GraphQL debug API](/api/graphql/) is also available without any compatibility guarauntees.
+For diagnostics use cases, the [Sourcegraph GraphQL debug API](/api/graphql/) is also available without any compatibility guarantees.
 
 <Callout type="warning">
 	<p>The Sourcegraph GraphQL API has historically been an internal interface

docs/batch-changes/batch-spec-cheat-sheet.mdx

@@ -82,7 +82,7 @@ changesetTemplate:
     # [...]
 
     # If we have an `outputs.projectName` we use it, otherwise we append the path
-    # of the workspace. If the path is emtpy (as is the case in the root folder),
+    # of the workspace. If the path is empty (as is the case in the root folder),
     # we ignore it.
     branch: |
         ${{ if eq outputs.projectName "" }}

docs/batch-changes/quickstart.mdx

@@ -99,7 +99,7 @@ The batch change's **changesets** still need to be published, which means they e
 So far, nothing has been created on your code hosts. To do so, you can tell Sourcegraph to either **publish** or **push** a changeset.
 
 -   **[Publishing](/batch-changes/publishing-changesets)** a changeset results in the creation of a merge request on your code host (e.g. a Pull Request on GitHub).
--   **[Pushing](/batch-changes/push-only-changesets)** a changeset (available on GitHub and GitLab only) results in pushing your code changes to a new branch on your code host without also creating a merge request. You are able to see any CI feedback set to trigger upon code-pushes in the Batch Changs UI.
+-   **[Pushing](/batch-changes/push-only-changesets)** a changeset (available on GitHub and GitLab only) results in pushing your code changes to a new branch on your code host without also creating a merge request. You are able to see any CI feedback set to trigger upon code-pushes in the Batch Changes UI.
 
 ### Configure code host credentials
 

docs/batch-changes/server-side.mdx

@@ -6,7 +6,7 @@
 
 <Callout type="info">
 	Running Batch Changes server-side is in Experimental stage and comes with
-	certains [limitations](#limitations).
+	certain [limitations](#limitations).
 </Callout>
 
 Batch Changes can use the Sourcegraph CLI in your local environment to [compute diffs](/batch-changes/how-src-executes-a-batch-spec) and create changesets. Local execution can be impractical for batch changes affecting hundreds or thousands of repositories, with large numbers of workspaces, or when batch change steps require CPU, memory, or disk resources that are unavailable locally.