diff --git a/docs/book.toml b/docs/book.toml
index 1a9bf5a7ed57175da44f4142c3ca468a38353137..7f17e3b945c4c71cc51eb799df5573835d61859a 100644
--- a/docs/book.toml
+++ b/docs/book.toml
@@ -10,3 +10,4 @@ git-repository-icon = "fa-gitlab"
 git-repository-url = "https://git.shivering-isles.com/shivering-isles/infrastructure-gitops/-/tree/main/docs"
 edit-url-template = "https://git.shivering-isles.com/-/ide/project/shivering-isles/infrastructure-gitops/edit/main/-/docs/{path}"
 additional-js = ["external-links.js"]
+additional-css = ["custom.css"]
diff --git a/docs/custom.css b/docs/custom.css
new file mode 100644
index 0000000000000000000000000000000000000000..1f40e361eb074fa339a6b8c155b95fdd375afea4
--- /dev/null
+++ b/docs/custom.css
@@ -0,0 +1,4 @@
+iframe[src^="https://www.youtube-nocookie.com/"] {
+    aspect-ratio: 16 / 9;
+    width: 100%;
+}
\ No newline at end of file
diff --git a/docs/src/concepts/gitops.md b/docs/src/concepts/gitops.md
index ef0f6eb2b42a903049dea2ad12db4dcb732a8eb7..3aa04bacf7166d0ab45e1df6eaaf0a84b60a5b18 100644
--- a/docs/src/concepts/gitops.md
+++ b/docs/src/concepts/gitops.md
@@ -4,10 +4,10 @@ The Shivering-Isles Infrastructure uses GitOps as central concept to maintain th
 
 The current tool of choice to implement GitOps in the Shivering-Isles Infrastructure is [FluxCD](https://fluxcd.io/) in combination with a monorepo.
 
-<iframe width="100%" height="480" src="https://www.youtube-nocookie.com/embed/lI03nh0EmaQ" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
+<iframe src="https://www.youtube-nocookie.com/embed/lI03nh0EmaQ" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
 
 ## GitOps Security
 
 To secure GitOps based deployments and reduce the risks of compromise, the GitOps deployment in the Shivering-Isles Infrastructure only accepts signed commits. This prevents a deployment of workload if an attackers mananges to push a commit onto the GitOps repository. The git forge itself is in charge of preventing rollbacks in the commit history. Rollbacks could be prevented by using git tags instead of git branches as reference, but are less practical.
 
-Further all secrets stored in the GitOps repository are encrypted using [SOPS](https://getsops.io/) along with unsensitive, but irrelevant information, such as dns names.
+Further all secrets stored in the GitOps repository are encrypted using [SOPS](https://getsops.io/) along with insensitive, but irrelevant information, such as dns names.
diff --git a/docs/src/concepts/sre.md b/docs/src/concepts/sre.md
index e84fefa8517cc8004139c9f353b594eb858d08bf..fb413b843f385760ac9082ef9ebe634a1d8e3d83 100644
--- a/docs/src/concepts/sre.md
+++ b/docs/src/concepts/sre.md
@@ -8,21 +8,26 @@ In the Shivering-Isles Infrastructure various apps have an own set of SLOs to va
 
 Besides maintaining reasonable SLOs, other SRE practices are implemented, such as post mortems and especially the practice of reducing toil. All components of the infrastructure have a maintenance budget, if it's depleted, it's time to fix the apps or get rid of it.
 
+Service Level Objectives
+---
+
+All public facing apps  and infrastructure components should have an Service Level Objective (SLO). The most basic SLOs for web apps are the availability and latency measured through the ingress controller. [An examples for an SLO definitions is the Shivering-Isles blog.](https://git.shivering-isles.com/shivering-isles/infrastructure-gitops/-/blob/797843c960f82a1974e2c3b632f0d45e5de9d6fe/apps/k8s01/blog/slo.yaml)
+
+Apps that provide more insight via metrics, can have app-specific SLOs to optimise for user impacting situations, that aren't covered by basic web metrics. [An example is the sidekiq SLO for Mastodon.](https://git.shivering-isles.com/shivering-isles/infrastructure-gitops/-/blob/797843c960f82a1974e2c3b632f0d45e5de9d6fe/apps/k8s01/mastodon/slo.yaml#L9-21)
+
+The actual objectives in the Shivering-Isles infrastructure are often relatively low around 95 percent.
+
 Learning about SRE
 ---
 
 A good start is this small video Series by Google:
 
-<iframe width="100%" height="480" src="https://www.youtube-nocookie.com/embed/?listType=playlist&list=PLIivdWyY5sqJrKl7D2u-gmis8h9K66qoj" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
-
+<iframe src="https://www.youtube-nocookie.com/embed/?listType=playlist&list=PLIivdWyY5sqJrKl7D2u-gmis8h9K66qoj" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
 
 Further there is the [Google SRE book](https://sre.google/sre-book/introduction/) as recommended read.
 
-Service Level Objectives
----
-
-All public facing apps should have an Service Level Objective (SLO). The most basic SLOs for web apps are the availability and latency measured throught the ingress controller. [An examples for an SLO definitions is the Shivering-Isles blog.](https://git.shivering-isles.com/shivering-isles/infrastructure-gitops/-/blob/797843c960f82a1974e2c3b632f0d45e5de9d6fe/apps/k8s01/blog/slo.yaml)
+Further there are some good talks from SREcon:
 
-Apps that provide more insight via metrics, can have app-specific SLOs to optimise for user impacting situations, that aren't covered by basic web metrics. [An example is the sidekiq SLO for Mastodon.](https://git.shivering-isles.com/shivering-isles/infrastructure-gitops/-/blob/797843c960f82a1974e2c3b632f0d45e5de9d6fe/apps/k8s01/mastodon/slo.yaml#L9-21)
+<iframe src="https://www.youtube-nocookie.com/embed/cKBRxLF22Mk" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
 
-The actual objectives in the Shivering-Isles infrastructure are often relatively low around 95 percent.
\ No newline at end of file
+<iframe src="https://www.youtube-nocookie.com/embed/jNP4nzIMK8E" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>