diff --git a/BACKLOG.md b/BACKLOG.md
new file mode 100644
index 0000000..84712ba
--- /dev/null
+++ b/BACKLOG.md
@@ -0,0 +1,97 @@
+# Backlog
+
+Offene Punkte, die bewusst nicht sofort erledigt wurden. Stand: 2026-07-30.
+
+---
+
+## 1. Zertifikatserneuerung braucht offene Ports — oder Umstellung auf DNS-01
+
+**Status:** offen, zeitkritisch ab ca. **2026-09-28**
+
+Das Cert für `selendis.axion1337.de` wurde am 2026-07-30 ausgestellt und läuft am
+**2026-10-28** ab. Traefik erneuert automatisch ca. 30 Tage vorher, also ab
+**Ende September 2026**.
+
+Traefik ist auf TLS-ALPN-01 konfiguriert
+(`--certificatesresolvers.letsencrypt.acme.tlschallenge=true`). Diese Challenge
+läuft ausschließlich über **Port 443, erreichbar aus dem offenen Internet**. Ist
+der Port zu diesem Zeitpunkt in der Hetzner-Cloud-Firewall gesperrt, scheitert die
+Erneuerung still mit:
+
+```
+urn:ietf:params:acme:error:connection :: Timeout during connect (likely firewall problem)
+```
+
+Traefik liefert dann sein Default-Self-Signed-Cert aus — Browser und `curl` brechen
+mit Zertifikatsfehler ab. **Das betrifft auch Gitea** (`rohana.axion1337.de`,
+Cert im selben Resolver), also die Erreichbarkeit dieses Repos per HTTPS.
+
+Eine IP-Allowlist für die Let's-Encrypt-Server ist **keine** Option: LE
+veröffentlicht seine Validierungs-IPs nicht und prüft seit Einführung der
+Multi-Perspective Validation aus mehreren Regionen gleichzeitig.
+
+Zwei Wege:
+
+- **A — Port 443 zur Erneuerung öffnen.** Nichts umbauen, aber alle ~60 Tage
+  daran denken. Fehleranfällig, weil das Scheitern nicht auffällt, bis jemand die
+  Seite aufruft.
+- **B — auf DNS-01 umstellen** (empfohlen). Validierung über einen TXT-Record,
+  **kein offener Port nötig**, Erneuerung läuft bei komplett dichter Firewall
+  durch. Voraussetzung: API-Token des DNS-Providers für `axion1337.de`, hinterlegt
+  als Secret für Traefik. Ermöglicht zusätzlich Wildcard-Certs
+  (`*.axion1337.de`), was künftige Subdomains ohne Portöffnung abdeckt.
+
+**Nächster Schritt:** Entscheidung A oder B. Bei B: DNS-Provider benennen und
+API-Token bereitstellen, dann Traefik-Resolver umstellen.
+
+---
+
+## 2. Pterodactyl-Host 157.90.155.206 nicht erreichbar — 2 Prometheus-Targets down
+
+**Status:** offen, Ursache liegt außerhalb dieses Hosts
+
+Zwei Scrape-Targets sind seit Längerem down — bereits vor dem Monitoring-Rework,
+also **kein Regressionsschaden** aus der Umstellung:
+
+| Job | Target | Fehler |
+|---|---|---|
+| `gameserver_cadvisor` | `157.90.155.206:8080` | `context deadline exceeded` |
+| `pterodactyl_host_node` | `157.90.155.206:9100` | `context deadline exceeded` |
+
+Der Host antwortet von `188.245.193.243` aus **nicht auf Ping** (100 % packet
+loss) und auf keinem der beiden Ports. Das Problem ist also nicht die
+Prometheus-Konfiguration, sondern die Erreichbarkeit des Zielhosts. Mögliche
+Ursachen, von wahrscheinlich nach unwahrscheinlich:
+
+1. Hetzner-Cloud-Firewall des Pterodactyl-Hosts lässt `188.245.193.243` nicht auf
+   8080/9100 — passend zum restriktiven Firewall-Setup.
+2. cAdvisor und node-exporter laufen dort nicht (mehr) bzw. binden nur auf
+   `127.0.0.1`.
+3. Host ist abgeschaltet oder umgezogen (IP veraltet).
+
+**Nächster Schritt:** auf dem Pterodactyl-Host prüfen, ob die beiden Exporter
+laufen und worauf sie binden, und die Firewall dort für `188.245.193.243` auf
+8080/9100 öffnen. Idealerweise nicht öffentlich, sondern über das private Netz —
+dieser Host hat `10.0.0.3/32` auf `enp7s0`; wenn der Pterodactyl-Host im selben
+Hetzner-vSwitch liegt, sollte über die privaten IPs gescrapt werden statt über
+die öffentlichen. Dann sind dafür gar keine offenen Ports im Internet nötig.
+
+Solange offen: die beiden Targets in Grafana/Alertmanager als *known down*
+behandeln, damit sie kein Dauer-Alerting erzeugen.
+
+---
+
+## Weitere Beobachtungen (nicht beauftragt, aber notiert)
+
+- **Prometheus Port 9090 ist öffentlich und ohne Auth erreichbar.** Nötig, weil
+  k3s-Cluster und Matrix-Server per `--web.enable-remote-write-receiver` dorthin
+  pushen. Ein offener Remote-Write-Receiver erlaubt Fremden aber das
+  **Einspeisen beliebiger Metriken** und das Auslesen aller Daten. Sollte per
+  Hetzner-Cloud-Firewall auf die Absender-IPs beschränkt werden — der Hinweis
+  steht als Kommentar in `monitoring/docker-compose.yml`, ist aber noch nicht
+  umgesetzt. Gleiches gilt für **Loki auf 3100**.
+- **Grafana-Admin-Credentials aus `.env` greifen nicht für die HTTP-API.** Der
+  Live-Admin wurde offenbar irgendwann in der UI geändert; `GF_SECURITY_ADMIN_*`
+  wirkt nur beim allerersten Start mit leerem Volume. Verifikation läuft deshalb
+  über `grafana.db` statt über die API. Kein Defekt, aber bei künftigen Checks
+  wissen.