diff --git a/slides/index.html b/slides/index.html
index bce01660..39447610 100644
--- a/slides/index.html
+++ b/slides/index.html
@@ -73,8 +73,9 @@ thing for now (stay tuned...)</td>
 
         <tr>
             <td>April 24th, 2018: GOTO Chicago - Kubernetes 101</td>
-            <td>&nbsp;</td>
+            <td><a class="slides" href="http://gotochgo2018.container.training/" /></td>
             <td><a class="attend" href="https://gotochgo.com/2018/workshops/88#k8s101" /></td>
+            <td>&nbsp;</td>
         </tr>
 
         <tr>
diff --git a/slides/kube/dashboard.md b/slides/kube/dashboard.md
index bdfa2b18..65e1ed33 100644
--- a/slides/kube/dashboard.md
+++ b/slides/kube/dashboard.md
@@ -256,9 +256,9 @@ The dashboard will then ask you which authentication you want to use.
 
 - It's safe if you use HTTPS URLs from trusted sources
 
---
-
-- It introduces new failure modes
-
 - Example: the official setup instructions for most pod networks
 
+--
+
+- It introduces new failure modes (like if you try to apply yaml from a link that's no longer valid)
+
diff --git a/slides/kube/rollout.md b/slides/kube/rollout.md
index aa8eb0f9..a6120b9f 100644
--- a/slides/kube/rollout.md
+++ b/slides/kube/rollout.md
@@ -33,6 +33,23 @@
 
 ---
 
+## Checking current rollout parameters
+
+- Recall how we build custom reports with `kubectl` and `jq`:
+
+.exercise[
+
+- Show the rollout plan for our deployments:
+  ```bash
+    kubectl get deploy -o json |
+            jq ".items[] | {name:.metadata.name} + .spec.strategy.rollingUpdate"
+  ```
+
+]
+
+---
+
+
 ## Rolling updates in practice
 
 - As of Kubernetes 1.8, we can do rolling updates with:
@@ -141,6 +158,38 @@ Our rollout is stuck. However, the app is not dead (just 10% slower).
 
 ---
 
+## What's going on with our rollout?
+
+- Why is our app 10% slower?
+
+- Because `MaxUnavailable=1`, so the rollout terminated 1 replica out of 10 available
+
+- Okay, but why do we see 2 new replicas being rolled out?
+
+- Because `MaxSurge=1`, so in addition to replacing the terminated one, the rollout is also starting one more
+
+---
+
+class: extra-details
+
+## The nitty-gritty details
+
+- We start with 10 pods running for the `worker` deployment
+
+- Current settings: MaxUnavailable=1 and MaxSurge=1
+
+- When we start the rollout:
+
+  - one replica is taken down (as per MaxUnavailable=1)
+  - another is created (with the new version) to replace it
+  - another is created (with the new version) per MaxSurge=1
+
+- Now we have 9 replicas up and running, and 2 being deployed
+
+- Our rollout is stuck at this point!
+
+---
+
 ## Recovering from a bad rollout
 
 - We could push some `v0.3` image
@@ -222,6 +271,8 @@ spec:
       minReadySeconds: 10
     "
   kubectl rollout status deployment worker
+  kubectl get deploy -o json worker |
+          jq "{name:.metadata.name} + .spec.strategy.rollingUpdate"
   ```
   ]