Mein Versäumnis in #696. Dort habe ich Ingress und ExternalName-Service für die NAS-Weboberfläche entfernt, weil sie auf das abgeschaltete nas-1 zeigten — den gatus-Check für denselben Hostnamen aber stehengelassen.
Gegen die Live-API geprüft:
Web Service 7: success = false
Die öffentliche Statusseite zeigt diesen Dienst seitdem als ausgefallen. Ich habe die Route entfernt und das, was sie beobachtet, stehen lassen.
Das Label wird als retired markiert statt umnummeriert — dieselbe Konvention wie bei Infrastructure 1 und 2.
Ein zweiter Fehler in derselben Legende
Die Wartungs-Legende behauptete Web Service 7 = Paperless. War es nie — der Slot hielt die NAS-Oberfläche, und Paperless wird in dieser Konfiguration überhaupt nicht geprüft.
Unangenehm daran: ich habe genau diese Legende in #699 um den fehlenden Eintrag Web Service 10 ergänzt, ohne den Rest zu verifizieren. Ein Durchgang, der ausdrücklich dieser Zuordnung galt, hat eine falsche Zeile überlebt. Jetzt ist jeder verbliebene Eintrag gegen seine URL geprüft:
Slot
URL
Web Service 1
auth.renner.uno/-/health/ready/
Web Service 2
gitea.renner.uno/api/v1/settings/api
Web Service 3
immich.renner.uno/api/server/ping
Web Service 4
ci.renner.uno/healthz
Web Service 5
dash.renner.uno/api/health
Web Service 6
home.renner.uno
Web Service 8
audiobooks.renner.uno/healthcheck
Web Service 9
music.renner.uno
Web Service 10
trmnl.renner.uno
Infrastructure 3
10.2.40.1 (DNS)
Infrastructure 4
mosquitto:1883 (TCP)
Paperless bleibt bewusst unüberwacht. Abdeckung hinzuzufügen ist eine eigene Entscheidung und nicht dasselbe wie eine Karte zu korrigieren, die lügt. Sag Bescheid, wenn du es willst.
Die Reloader-Annotation aus #700 kam nach der ConfigMap-Änderung, die sie beobachtet. Reloader reagiert auf Events, nicht auf Zustand — also feuerte nie eines, und der Pod läuft weiterhin mit der Endpunktliste von vor #699 und probet pbs2 weiter. Verifiziert: Pod unverändert 26 h alt, Annotation vorhanden, Reloader-Log seit dem Start am 27.08. leer.
Nebenbei bestätigt der Reloader-Log empirisch, was die Doku offenließ: „KUBERNETES_NAMESPACE is unset, will detect changes in all namespaces."
Diese Änderung ist ein echtes ConfigMap-Event. Sie sollte den Pod neu starten und damit beide Drifts auflösen — den pbs2-Rest und diesen Check.
Ich habe den Pod nicht von Hand neu gestartet, obwohl das die Drift sofort behoben hätte. Das hätte genau den Mechanismus übersprungen, der hier zu prüfen ist.
**Mein Versäumnis in #696.** Dort habe ich Ingress und ExternalName-Service für die NAS-Weboberfläche entfernt, weil sie auf das abgeschaltete nas-1 zeigten — den gatus-Check für denselben Hostnamen aber stehengelassen.
Gegen die Live-API geprüft:
```
Web Service 7: success = false
```
Die öffentliche Statusseite zeigt diesen Dienst seitdem als ausgefallen. Ich habe die Route entfernt und das, was sie beobachtet, stehen lassen.
Das Label wird als retired markiert statt umnummeriert — dieselbe Konvention wie bei Infrastructure 1 und 2.
## Ein zweiter Fehler in derselben Legende
Die Wartungs-Legende behauptete `Web Service 7 = Paperless`. **War es nie** — der Slot hielt die NAS-Oberfläche, und Paperless wird in dieser Konfiguration überhaupt nicht geprüft.
Unangenehm daran: ich habe genau diese Legende in #699 um den fehlenden Eintrag `Web Service 10` ergänzt, **ohne den Rest zu verifizieren**. Ein Durchgang, der ausdrücklich dieser Zuordnung galt, hat eine falsche Zeile überlebt. Jetzt ist jeder verbliebene Eintrag gegen seine URL geprüft:
| Slot | URL |
|---|---|
| Web Service 1 | auth.renner.uno/-/health/ready/ |
| Web Service 2 | gitea.renner.uno/api/v1/settings/api |
| Web Service 3 | immich.renner.uno/api/server/ping |
| Web Service 4 | ci.renner.uno/healthz |
| Web Service 5 | dash.renner.uno/api/health |
| Web Service 6 | home.renner.uno |
| Web Service 8 | audiobooks.renner.uno/healthcheck |
| Web Service 9 | music.renner.uno |
| Web Service 10 | trmnl.renner.uno |
| Infrastructure 3 | 10.2.40.1 (DNS) |
| Infrastructure 4 | mosquitto:1883 (TCP) |
**Paperless bleibt bewusst unüberwacht.** Abdeckung hinzuzufügen ist eine eigene Entscheidung und nicht dasselbe wie eine Karte zu korrigieren, die lügt. Sag Bescheid, wenn du es willst.
## Das ist zugleich der Test für #700
Die Reloader-Annotation aus #700 kam **nach** der ConfigMap-Änderung, die sie beobachtet. Reloader reagiert auf Events, nicht auf Zustand — also feuerte nie eines, und der Pod läuft weiterhin mit der Endpunktliste von vor #699 und probet pbs2 weiter. Verifiziert: Pod unverändert 26 h alt, Annotation vorhanden, Reloader-Log seit dem Start am 27.08. leer.
Nebenbei bestätigt der Reloader-Log empirisch, was die Doku offenließ: *„KUBERNETES_NAMESPACE is unset, will detect changes in all namespaces."*
Diese Änderung ist ein echtes ConfigMap-Event. Sie sollte den Pod neu starten und damit **beide** Drifts auflösen — den pbs2-Rest und diesen Check.
Ich habe den Pod nicht von Hand neu gestartet, obwohl das die Drift sofort behoben hätte. Das hätte genau den Mechanismus übersprungen, der hier zu prüfen ist.
#696 deleted the Ingress and ExternalName Service for the NAS file UI because
they pointed at nas-1, which is off. It did not delete the gatus check for the
same hostname, so the public status page has been showing Web Service 7 as
failing ever since — verified against the live API, success: false.
That was my omission in #696: I removed the route and left the thing watching
it.
The label is retired rather than renumbered, matching Infrastructure 1 and 2.
The maintainer legend claimed Web Service 7 was Paperless. It never was — the
slot held the NAS file UI, and nothing in this config checks Paperless at all.
I added the missing Web Service 10 entry to this same map in #699 without
verifying the rest of it, which is how a wrong line survived a pass that was
supposed to be about exactly this map. Every remaining entry is now checked
against its URL.
Paperless is genuinely unmonitored here and is left that way deliberately:
adding coverage is a separate decision from correcting a map that lies.
This is also the ConfigMap change that exercises the Reloader annotation from
#700. That annotation landed after the ConfigMap it watches had already
changed, so no event ever fired and the pod kept serving the pre-#699 endpoint
list, still probing pbs2. This edit should reload it and clear both.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Mein Versäumnis in #696. Dort habe ich Ingress und ExternalName-Service für die NAS-Weboberfläche entfernt, weil sie auf das abgeschaltete nas-1 zeigten — den gatus-Check für denselben Hostnamen aber stehengelassen.
Gegen die Live-API geprüft:
Die öffentliche Statusseite zeigt diesen Dienst seitdem als ausgefallen. Ich habe die Route entfernt und das, was sie beobachtet, stehen lassen.
Das Label wird als retired markiert statt umnummeriert — dieselbe Konvention wie bei Infrastructure 1 und 2.
Ein zweiter Fehler in derselben Legende
Die Wartungs-Legende behauptete
Web Service 7 = Paperless. War es nie — der Slot hielt die NAS-Oberfläche, und Paperless wird in dieser Konfiguration überhaupt nicht geprüft.Unangenehm daran: ich habe genau diese Legende in #699 um den fehlenden Eintrag
Web Service 10ergänzt, ohne den Rest zu verifizieren. Ein Durchgang, der ausdrücklich dieser Zuordnung galt, hat eine falsche Zeile überlebt. Jetzt ist jeder verbliebene Eintrag gegen seine URL geprüft:Paperless bleibt bewusst unüberwacht. Abdeckung hinzuzufügen ist eine eigene Entscheidung und nicht dasselbe wie eine Karte zu korrigieren, die lügt. Sag Bescheid, wenn du es willst.
Das ist zugleich der Test für #700
Die Reloader-Annotation aus #700 kam nach der ConfigMap-Änderung, die sie beobachtet. Reloader reagiert auf Events, nicht auf Zustand — also feuerte nie eines, und der Pod läuft weiterhin mit der Endpunktliste von vor #699 und probet pbs2 weiter. Verifiziert: Pod unverändert 26 h alt, Annotation vorhanden, Reloader-Log seit dem Start am 27.08. leer.
Nebenbei bestätigt der Reloader-Log empirisch, was die Doku offenließ: „KUBERNETES_NAMESPACE is unset, will detect changes in all namespaces."
Diese Änderung ist ein echtes ConfigMap-Event. Sie sollte den Pod neu starten und damit beide Drifts auflösen — den pbs2-Rest und diesen Check.
Ich habe den Pod nicht von Hand neu gestartet, obwohl das die Drift sofort behoben hätte. Das hätte genau den Mechanismus übersprungen, der hier zu prüfen ist.