diff --git a/docs/issues/0030-der-restore-ist-nie-geprobt-sicherungen-sind.md b/docs/issues/0030-der-restore-ist-nie-geprobt-sicherungen-sind.md
index 202d4ba..5841048 100644
--- a/docs/issues/0030-der-restore-ist-nie-geprobt-sicherungen-sind.md
+++ b/docs/issues/0030-der-restore-ist-nie-geprobt-sicherungen-sind.md
@@ -434,3 +434,25 @@ Prometheus führt weiterhin die alte Fassung — nachgemessen über die Rules-AP
 Fehlschlag-Alarm ist davon nicht betroffen und schon jetzt scharf**, nur die zwei
 Stille-Alarme brauchen ein `git pull` und einen Reload auf dem Host. Seit die Configs als
 Verzeichnis gemountet sind (#0083), genügt dafür ein Reload ohne Neuanlage.
+
+### Nachgeprüft nach Pull und Reload (2026-08-21)
+
+Alle drei Regeln laufen mit `health=ok`, `RestoreDrillStale` mit Präfix-Matcher und dem
+CronJob-Namen in der Meldung, `BackupCronJobMissing` einschließlich `restore-drill-media`.
+
+⚠️ **`health=ok` heißt nur, dass eine Regel auswertbar ist — nicht, dass sie etwas sieht.**
+Deshalb zusätzlich die Serien geprüft, auf denen sie steht:
+
+| Serie | Wert |
+|---|---|
+| `kube_cronjob_info{cronjob="restore-drill-media"}` | 1 |
+| `kube_cronjob_status_last_schedule_time{…}` | **keine Serie** |
+| `kube_cronjob_created{…}` | vorhanden, 0,3 h alt |
+| Fallback-Ausdruck der Regel | liefert **beide** Proben, je eine Serie |
+
+**Der Fallback ist damit nicht mehr theoretisch, sondern vorgeführt.** Ein frisch
+angelegter CronJob hat noch keine `last_schedule_time` — ein manuell ausgelöster Lauf
+setzt sie nicht, und der erste planmäßige ist der 2026-09-04. Ohne das
+`or kube_cronjob_created` stünde die Regel für die neue Probe über einen Ausdruck ohne
+Serie und könnte **nie** feuern: grün, gesund und blind. Der Ausdruck, den jemand vor
+einer Woche vorsorglich so gebaut hat, trägt heute zum ersten Mal echtes Gewicht.