diff --git a/docs/helmchart.md b/docs/helmchart.md
index 592711333c09e522c9c3793b1a26064af3ee16e4..1a18ac560220ab5e01bdcbdb10b1ad80cf35ee51 100644
--- a/docs/helmchart.md
+++ b/docs/helmchart.md
@@ -184,4 +184,27 @@ $ helm delete single-sign-on
 
 > **WARNING**: Executing the `delete` command will delete all data that is related to the applications. Don't run this command in a production environment if you are not absolutely sure that you have a restorable backup of your data.
 
+## Known issues
+
+Short after the installation, the Hydra and Kratos pod will error a few times
+before they run correctly and enter the "Ready" state. This is because the Hydra
+helm chart is not built for running your PostgresQL server in
+the same Kubernetes cluster as the helm chart. The problem is that the Hydra
+"automigration" usually runs as a pre-install step of the helm chart. We cannot
+do that because in this chart the Hydra database is actually installed after
+pre-install hooks have finished running. Ory doesn't want to solve this issue,
+because they're fundamentally against running databases on Kubernetes.
+
+As a result, we've had to include [jobs that run the
+[Hydra](https://open.greenhost.net/stackspin/single-sign-on/-/blob/main/helmchart/single-sign-on/templates/job-migration-hydra.yaml)
+and [Kratos
+migration](https://open.greenhost.net/stackspin/single-sign-on/-/blob/main/helmchart/single-sign-on/templates/job-migration-kratos.yaml)
+inside our single sign-on helm chart. However, we can't modify the Hydra and
+Kratos pods without forking the whole helm charts. As a result the Hydra and
+Kratos container will fail to come up before those jobs have finished.
+
+Once the jobs have finished, they should work well, though. The migration jobs
+are run on upgrades as well, but might cause less issues there because they take
+less time.
+
 [^1]: If you want to test a version that is not on the `main` branch yet, use `https://open.greenhost.net/api/v4/projects/8/packages/helm/unstable`