docs: fixed some typos, formatting, grammar (#11540)

# Which Problems Are Solved - Typos - Punctuation - Markdown table formatting - ... (A bunch of issues my editor gave) # How the Problems Are Solved # Additional Changes # Additional Context
2026-11-01 11:52:15 +00:00 · 2026-02-13 07:45:17 +01:00
parent b0609aa861
commit 9b064d8b74
127 changed files with 764 additions and 760 deletions
@@ -16,7 +16,7 @@ If you on the other hand want users to be able to federate their accounts from a

 Further ZITADEL provided the possibility to disable registration on each IDP with the introduction of IDP Templates.

-To address this, we are going to change the behavior of the setting mentioned above, so that if disable, it will only prevent local registration. Registration of a federated user will still be possible - if not disabled by the corresponding IDP Template.
+To address this, we are going to change the behavior of the setting mentioned above, so that if disabled, it will only prevent local registration. Registration of a federated user will still be possible - if not disabled by the corresponding IDP Template.

 ## Statement

@@ -14,7 +14,7 @@ Due to storage optimizations ZITADEL changes the behavior of sequences.
 This change improves command (create, update, delete) performance of ZITADEL.

 Sequences are no longer unique inside an instance.
-From now on sequences are upcounting per aggregate id.
+From now on sequences are counting up per aggregate id.
 For example sequences of newly created users begin at 1.
 Existing sequences remain untouched.

@@ -27,7 +27,7 @@ As soon as the release version is published, we will include the version here.

 If you use the ListEvents API to scrape events use the creation date instead of the sequence.
 If you use sequences on a list of objects it's no longer guaranteed to have unique sequences across the list.
-Therefore it's recommended to use the change data of the objects instead.
+Therefore, it's recommended to use the change data of the objects instead.

 ## Impact

@@ -12,7 +12,7 @@ Date: Calendar week 41/42 2023

 Versions >= 2.39.0 require the cockroach database user of ZITADEL to be granted to the `VIEWACTIVITY` grant. This can either be reached by grant the role manually or execute the `zitadel init` command.

-Cockroach versions 22.2 < 22.2.11 and 23.1 < 23.1.4 will fail the migration. Please make sure to upgrade to more recent versions first. ZITADEL recommends to use the latest stable version of Cockroachdb.
+Cockroach versions 22.2 < 22.2.11 and 23.1 < 23.1.4 will fail the migration. Please make sure to upgrade to more recent versions first. ZITADEL recommends to use the latest stable version of CockroachDB.

 ## Statement

@@ -22,7 +22,7 @@ To query correct order of events the cockroach database user of ZITADEL needs ad

 Before migrating to versions >= 2.39.0 make sure the cockroach database user has sufficient grants.

-Cockroachdb version is up to date.
+CockroachDB version is up to date.

 ## Impact

@@ -15,7 +15,7 @@ This advisory applies to self-hosted ZITADEL installations with custom roles to
 ## Description

 In upcoming ZITADEL versions, RBAC also applies to [system users defined in the ZITADEL runtime configuration](/guides/integrate/zitadel-apis/access-zitadel-system-api#runtime-configuration).
-This enables fine grained access control to the system API as well as other APIs for system users.
+This enables fine-grained access control to the system API as well as other APIs for system users.
 ZITADEL defines the new default roles *SYSTEM_OWNER* and *SYSTEM_OWNER_VIEWER*.
 System users without any memberships defined in the configuration will be assigned the *SYSTEM_OWNER* role.
 **Self-hosting users who define their own custom mapping at the *InternalAuthZ.RolePermissionMappings* configuration section**, have to define the *SYSTEM_OWNER* role in their configuration too to be able to access the system API with the default system user membership.
@@ -10,17 +10,17 @@ Date: 2024-05-28

 ## Description

-There were rare cases where Cockroachdb got blocked during runtime of ZITADEL and returned `WRITE_TOO_OLD`-errors to ZITADEL. The root cause of the problem is described in [this github issue of the database](https://github.com/cockroachdb/cockroach/issues/77119). The workaround provided by the database is enabling the `enable_durable_locking_for_serializable`-flag as described [here](https://github.com/cockroachdb/cockroach/issues/75456#issuecomment-1936277716).
+There were rare cases where CockroachDB got blocked during runtime of ZITADEL and returned `WRITE_TOO_OLD`-errors to ZITADEL. The root cause of the problem is described in [this GitHub issue of the database](https://github.com/cockroachdb/cockroach/issues/77119). The workaround provided by the database is enabling the `enable_durable_locking_for_serializable`-flag as described [here](https://github.com/cockroachdb/cockroach/issues/75456#issuecomment-1936277716).

 Because enabling flags requires admin privileges the statement must be executed manually or by executing `zitadel init` command.

 ## Statement

-Ensure lock distribution for `FOR UPDATE`-statements on Cockroachdb.
+Ensure lock distribution for `FOR UPDATE`-statements on CockroachDB.

 ## Mitigation

-Cockroachdb version >= 23.2.
+CockroachDB version >= 23.2.

 ## Impact

@@ -17,13 +17,13 @@ they are reduced into projections in bulk batches. Projections allow for efficie

 We've investigated multiple reports of outdated projections.
 For example created users missing in get requests, or missing data after a ZITADEL upgrade[^1].
-The conclusion is that the transaction in which we perform a bulk of queries can timeout.
+The conclusion is that the transaction in which we perform a bulk of queries can time out.
 The old setting defined a transaction duration of 500ms for a bulk of 200 events.
 A single event may create multiple statements in a single projection.
 A timeout may occur even if the actual bulk size is less than 200,
-which then results in more back-pressure on a busy system, leading to more timeouts and effectively dead-locking a projection.
+which then results in more back-pressure on a busy system, leading to more timeouts and effectively deadlocking a projection.

-Increasing or disabling the projection transaction duration solved dead-locks in all reported cases.
+Increasing or disabling the projection transaction duration solved deadlocks in all reported cases.
 We've decided to increase the transaction duration to 1 minute.
 Due to the high value it is functionally similar to disabling,
 however it still provides a safety net for transaction that do freeze,
@@ -39,7 +39,7 @@ This change was submitted in the following PR:

 ## Mitigation

-If you have a custom configuration for projections, this update will not apply to your system or some projections. When encountering projection dead-lock consider increasing the timeout to the new default value.
+If you have a custom configuration for projections, this update will not apply to your system or some projections. When encountering projection deadlock consider increasing the timeout to the new default value.

 Note that entries under `Customizations` overwrite the global settings for a single projection.

@@ -21,7 +21,7 @@ Last updated: 2025-05-19

 ### Background

-Zitadel uses a eventstore table as main source of truth for state changes.
+Zitadel uses an eventstore table as main source of truth for state changes.
 Projections are tables which provide alternative views of state, which are built using events.
 In order to know which events are reduced into projections, we use a `position` column in the eventstore and a dedicated table which records the current state.

@@ -31,7 +31,7 @@ Zitadel prior to the listed version had a precision bug. The `position` column u

 ## Impact

-During a past attempt to fix this, we got reports of failing projections inside Zitadel. Because the precision became exact certain compare operations like *equal*, *less then*, etc would now return different results. This was because the values in `current_states` would already have lost precision from a broken version. This might happen to **some** deployments or projections: there is only a small probability.
+During a past attempt to fix this, we got reports of failing projections inside Zitadel. Because the precision became exact certain compare operations like *equal*, *less than*, etc. would now return different results. This was because the values in `current_states` would already have lost precision from a broken version. This might happen to **some** deployments or projections: there is only a small probability.

 We are releasing the fix again and your system might get affected.

@@ -6,7 +6,7 @@ sidebar_label: Technical Advisories
 Technical advisories are notices that report major issues with ZITADEL Self-Hosted or the ZITADEL Cloud platform that could potentially impact security or stability in production environments.
 These advisories may include details about the nature of the issue, its potential impact, and recommended mitigation actions.

-Users are strongly encouraged to evaluate these advisories and consider the recommended mitigation actions independently from their version upgrade schedule.
+Users are strongly encouraged to evaluate these advisories and consider the recommended mitigation actions independently of their version upgrade schedule.
 We understand that these advisories may include breaking changes, and we aim to provide clear guidance on how to address these changes.

 <table>
@@ -64,7 +64,7 @@ We understand that these advisories may include breaking changes, and we aim to
      keep the library up-to-date, the management console UI will loose its dynamic theming
      capability. If you need users to have your branding settings (background-,
      button-, link and text coloring) you should implement your own user
-      facing UI yourself and not use ZITADELs management console UI.
+      facing UI yourself and not use ZITADEL's management console UI.
      ZITADEL hosted Login-UI is not affected by this change.
    </td>
    <td>2.40.0</td>
@@ -96,7 +96,7 @@ We understand that these advisories may include breaking changes, and we aim to
      Due to storage optimizations ZITADEL changes the behavior of sequences.
      This change improves command (create, update, delete) performance of ZITADEL.
      Sequences are no longer unique inside an instance.
-      From now on sequences are upcounting per aggregate id.
+      From now on sequences are incrementing per aggregate id.
      For example sequences of newly created users begin at 1.
      Existing sequences remain untouched.
    </td>
@@ -113,7 +113,7 @@ We understand that these advisories may include breaking changes, and we aim to
      Migrating to versions &gt;= 2.39 from &lt; 2.39 will cause down time during setup starts and the new version is started.
      This is caused by storage optimizations which replace the `eventstore.events` database table with the new `eventstore.events2` table.
      All existing events are migrated during the execution of the `zitadel setup` command.
-      New events will be inserted into the new `eventstore.events2` table. The old table `evetstore.events` is renamed to `eventstore.events_old` and will be dropped in a future release of ZITADEL.
+      New events will be inserted into the new `eventstore.events2` table. The old table `eventstore.events` is renamed to `eventstore.events_old` and will be dropped in a future release of ZITADEL.
    </td>
    <td>2.39.0</td>
    <td>Calendar week 41/42 2023</td>
@@ -256,7 +256,7 @@ We understand that these advisories may include breaking changes, and we aim to

 If you want to stay up to date on our technical advisories, we recommend subscribing to our [Technical Advisory mailing list](https://share-eu1.hsforms.com/1NAOUyAMmRzSnB7uP665xHA2dljbt) or visiting our [website](https://zitadel.com/technical-advisory).

-As ZITADEL Cloud customer, you can also login to the <a href="https://zitadel.com/admin">ZITADEL Customer Portal</a> and enable the Technical Advisory <a href="https://zitadel.com/admin/settings">Notifications</a> in your settings.
+As ZITADEL Cloud customer, you can also log in to the <a href="https://zitadel.com/admin">ZITADEL Customer Portal</a> and enable the Technical Advisory <a href="https://zitadel.com/admin/settings">Notifications</a> in your settings.

 ## Categories

@@ -21,7 +21,7 @@ Also check if "block all cookies" is active. If so please disable this setting.

 To make sure, that your new settings will trigger, please restart your mobile phone and try it again.

-**Settings > Safari > Advanced > Experimental Features > disable: „SameSite strict enforcement (ITP)“**
+**Settings > Safari > Advanced > Experimental Features > disable: "SameSite strict enforcement (ITP)"**

 ![Same Site Strict Enforcement](../../public/img/manuals/errors/same-site-strict.png)

@@ -50,7 +50,7 @@ End-users authenticate to an application in your frontend project.
 The frontend then sends requests to the backend, validates the token with ZITADEL's introspection endpoint, and returns a payload to the frontend.
 The backend returns the error `invalid audience (APP-Zxfako)`.

-You must add the scope `urn:zitadel:iam:org:project:id:{projectId}:aud` to the auth request that is send from the front end.
+You must add the scope `urn:zitadel:iam:org:project:id:{projectId}:aud` to the auth request that is sent from the front end.
 Replace `projectId` with the projectId of your backend.

 ### Accessing ZITADEL's APIs
@@ -59,7 +59,7 @@ You have a project for a frontend application.
 The application should also access the API of your ZITADEL, for example to pull a list of all users and display them on a user page.
 End-users authenticate to the application in the frontend project, but when calling the management API you get the error `invalid audience (APP-Zxfako)`.

-You must add the scope `urn:zitadel:iam:org:project:id:zitadel:aud` to the auth request that is send from the front end.
+You must add the scope `urn:zitadel:iam:org:project:id:zitadel:aud` to the auth request that is sent from the front end.

 When accessing your ZITADEL instance's APIs they act as a resource server.
 You can check the Management Console or via API and see that when you open your default organization there exists a project "ZITADEL" that contains different applications for each API and the Console.
@@ -68,11 +68,11 @@ Instead of `urn:zitadel:iam:org:project:id:zitadel:aud` you could also use `urn:

 ## WebFinger requirement for Tailscale

-The WebFinger requirement and setup is a step a user has to take outside of their IdP set-up. WebFinger is a protocol which supports the ability for OIDC issuer discovery, and we use it to prove that the user has administrative control over the domain and to retrieve the issuer. This is a requirement we have in place for all users, regardless of their IdP, who use custom OIDC with Tailscale.
+The WebFinger requirement and setup is a step a user has to take outside their IdP set-up. WebFinger is a protocol which supports the ability for OIDC issuer discovery, and we use it to prove that the user has administrative control over the domain and to retrieve the issuer. This is a requirement we have in place for all users, regardless of their IdP, who use custom OIDC with Tailscale.

-On their Custom Domain, e.g example.com, users need to host a WebFinger endpoint at https://example.com/.well-known/webfinger. When queried, this endpoint returns a JSON response detailing the issuer. Users would need to host the endpoint with the link to the ZITADEL issuer. Tailscale only looks up this endpoint once when a user signs up, and will only look up this endpoint again if the user needs to make a configuration change to their identity provider.
+On their Custom Domain, e.g. example.com, users need to host a WebFinger endpoint at https://example.com/.well-known/webfinger. When queried, this endpoint returns a JSON response detailing the issuer. Users would need to host the endpoint with the link to the ZITADEL issuer. Tailscale only looks up this endpoint once when a user signs up, and will only look up this endpoint again if the user needs to make a configuration change to their identity provider.

-The requirements and a set up guide is detailed in the [Tailscale documentation](https://tailscale.com/kb/1240/sso-custom-oidc/).
+The requirements and a set-up guide is detailed in the [Tailscale documentation](https://tailscale.com/kb/1240/sso-custom-oidc/).

 ## Login not possible. The organization of the user must be granted to the project

@@ -103,7 +103,7 @@ You do have two possibilities.
 1. Go to the organization, who owns the project, where the user tries to authenticate.
 2. Navigate to the Project Grants page of the needed project
 3. Click on the "New" button
-4. Search for the organization to which you want to grant the project (e.g Organization B)
+4. Search for the organization to which you want to grant the project (e.g. Organization B)
 5. Select the roles you want to grant
 6. Click save