diff --git a/aidlc-docs/features/react-frontend/audit.md b/aidlc-docs/features/react-frontend/audit.md
index 58b416a..c853426 100644
--- a/aidlc-docs/features/react-frontend/audit.md
+++ b/aidlc-docs/features/react-frontend/audit.md
@@ -612,3 +612,15 @@
 **Context**: Post-workflow follow-up (feature already marked Complete); continues the `feature/analytics_uptime_dashboard` branch, clarifying the deployment steps before the Umami container has successfully started on the Pi. Documentation-only change (no code/build impact).
 
 ---
+
+## Post-Completion Follow-up: ufw Firewall Rule Missing for Port 3001 (Connection Reset by Peer)
+
+**Timestamp**: 2026-07-25T23:05:00Z
+
+**User Input**: "ik krijg nu: curl http://192.168.1.103:3001/api/heartbeat curl: (56) Recv failure: Connection reset by peer"
+
+**AI Response**: "Diagnosed via `podman ps`/`podman logs`/`ss -tlnp` that the Umami container and rootlessport forwarder were both healthy and correctly listening on `192.168.1.103:3001`, ruling out an application/container issue. Root cause found in `sudo ufw status verbose`: an explicit `ALLOW` rule exists for `3000/tcp` from `192.168.1.102` (the reverse-proxy Pi), but no equivalent rule exists for `3001/tcp`, and ufw's default incoming policy is `deny` — so the request is blocked even when curled from Pi Main itself, since it targets the real host IP rather than loopback. Added a new firewall step to `umami-setup.md` (`sudo ufw allow from 192.168.1.102 to any port 3001 proto tcp` + `ufw reload`), inserted before the heartbeat-check step, plus a troubleshooting tip to test via `localhost:3001` (bypasses the firewall) to isolate firewall vs. container issues. Added the missing ufw rule to the outstanding manual steps list."
+
+**Context**: Post-workflow follow-up (feature already marked Complete); continues the `feature/analytics_uptime_dashboard` branch, resolving a connectivity blocker discovered while the user was testing the Umami container on Pi Main. Documentation-only change (no code/build impact); the actual `ufw allow` command still needs to be run by the user on Pi Main.
+
+---
diff --git a/aidlc-docs/features/react-frontend/operations/monitoring/umami-setup.md b/aidlc-docs/features/react-frontend/operations/monitoring/umami-setup.md
index 680a4bd..39af2d9 100644
--- a/aidlc-docs/features/react-frontend/operations/monitoring/umami-setup.md
+++ b/aidlc-docs/features/react-frontend/operations/monitoring/umami-setup.md
@@ -73,14 +73,30 @@ onder een eigen `umami`-user te draaien in plaats van je eigen hoofdaccount:
    cd ~/umami
    podman-compose up -d
    ```
-4. Controleer dat Umami draait en bereikbaar is op het interne netwerk. Let op: de
+4. **Firewall (ufw) openzetten voor poort 3001.** Pi Main gebruikt `ufw` met als default
+   policy `deny incoming` — net als poort `3000` (Gitea) al een expliciete regel heeft
+   voor het interne IP van de reverse-proxy-Pi, heeft `3001` (Umami) dezelfde regel nodig,
+   anders krijg je bij het testen `curl: (56) Recv failure: Connection reset by peer`
+   (ook wanneer je *op Pi Main zelf* naar het publieke IP `192.168.1.103` curl't — dat
+   gaat namelijk nog steeds via de firewall-INPUT-chain, in tegenstelling tot
+   `localhost`/`127.0.0.1`):
+   ```bash
+   sudo ufw allow from 192.168.1.102 to any port 3001 proto tcp
+   sudo ufw reload
+   ```
+   Controleer met `sudo ufw status verbose` dat er nu een regel voor `3001/tcp` staat,
+   analoog aan de bestaande regel voor `3000/tcp`.
+5. Controleer dat Umami draait en bereikbaar is op het interne netwerk. Let op: de
    **externe** poort is `3001`, niet het gebruikelijke `3000` — die poort is op deze Pi al
    in gebruik door Gitea (`bind: address already in use` bij het opstarten van de
    container als je toch `3000` gebruikt):
    ```bash
    curl http://192.168.1.103:3001/api/heartbeat
    ```
-   Dit zou een JSON-antwoord met `"ok"` moeten teruggeven.
+   Dit zou een JSON-antwoord met `"ok"` moeten teruggeven. Krijg je toch een
+   `Connection reset by peer`, controleer dan eerst of `curl http://localhost:3001/api/heartbeat`
+   (dus via loopback, buiten de firewall om) wél werkt — zo ja, dan zit het probleem
+   zeker in de ufw-regel hierboven en niet in Umami/Podman zelf.
 
 > **Let op — na een wijziging aan `podman-compose.yml`/`.env` (bv. een andere poort):**
 > `podman-compose up -d` update alléén containers waarvan de configuratie is gewijzigd,
@@ -174,6 +190,7 @@ dit toch lokaal testen, zet dan tijdelijk beide waarden in `.env.local` (zie
 ## Openstaande handmatige stappen
 - [ ] Dedicated `umami`-user aanmaken op Pi Main (incl. subuid/subgid-check en `loginctl enable-linger`).
 - [ ] `podman-compose up -d` daadwerkelijk draaien als de `umami`-user op Pi Main.
+- [ ] ufw-regel toevoegen voor poort `3001/tcp` (analoog aan de bestaande `3000/tcp`-regel) op Pi Main.
 - [ ] Systemd user-service instellen (onder de `umami`-user) voor auto-start na reboot.
 - [ ] DNS-record + certbot voor `analytics.slpsoftware.nl` op de reverse-proxy-Pi.
 - [ ] Standaard Umami-wachtwoord direct wijzigen na eerste login.