diff --git a/keycloak.md b/keycloak.md
index 6cc37e1..66d0dec 100644
--- a/keycloak.md
+++ b/keycloak.md
@@ -401,7 +401,7 @@ This chart renders **no** NetworkPolicy. If one is ever added, it has to allow 7
 
 **The install-test runs with two replicas**, and the rollout is complete only when **both** pods are Ready — so a second replica that cannot start, deadlocks on the schema migration lock or fights the first over the database fails the run. Measured in Gitea PR #87: **71.8 seconds** from `helm install` to both pods Ready, 0 restarts — three runs, all three the same.
 
-**Read that as an observation and not as an invariant.** Three further runs of identical manifests in PR #92 measured **101s with one restart**, **82s with none**, and **191s with none**. The fastest and the slowest run restarted nothing and the middle one did, so it is not the pod spec — and it is not simply a loaded runner either, which was the first explanation and did not survive the 191s run. **What the restart was could not be established, because the harness dumps container logs only when a run fails** — a green run cannot explain a restart it reports. Whoever needs that answer has to make the final-state step print the restart reasons when a counter is above zero.
+**Read that as an observation and not as an invariant.** Four runs of an identical pod spec in PR #92 measured **101s / one restart**, **82s / none**, **191s / none** and **101s / one restart**. So: intermittent on an unchanged spec, always exactly one restart on one pod about 35s before it reports Ready, and **not** a function of the runner's speed — the fastest and the slowest run restarted nothing, which is what disproved the first explanation. **What the restart is could not be established, because the harness dumps container logs only when a run fails** — a green run cannot explain a restart it reports. Answering it means making the final-state step print the restart reasons whenever a counter is above zero. A first install that serializes two replicas on the Liquibase migration lock is a plausible place for one, but that is a hypothesis and nothing has measured it.
 
 **What that does *not* prove is that `jdbc-ping` found the peer**, and reading it that way is the mistake this paragraph exists to prevent. Readiness reports *this* node's health, so a node that never found its peer is Ready, healthy and alone — and two such nodes are two islands that each believe they are the cluster. The Infinispan view has to be read out of the log, which is what step 2 of the first-install checklist is for. So the test rules out the louder half and leaves the quiet half to a human.