The pack./packwiz service was removed operationally long ago, but several plan docs still presented pack. as a live caddy vhost / DNS subdomain and render-pack.sh as a current tool. Remove those references from the current-architecture docs (overview, caddy, tooling, uptime-kuma, letsencrypt, mc-backup); leave the migration log (04-mods.md), superseded banner (04-packwiz.md), commit history (12-build-order.md), and planned landing rework (18) intact as deliberate history. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2.6 KiB
10 — Uptime Kuma
Distinct from
plan/15-mc-status.md: Kuma is the uptime history + alerting backend; mc-status is the live data feed for the landing's server card. Both pingminecraftovermcnetbut serve different purposes.
Status monitoring + public status page. Service uptime-kuma
(louislam/uptime-kuma:1), web UI on :3001, reached only through caddy at
https://status.${BASE_DOMAIN}. Joined to mcnet, so it can probe every other
service by its internal container name.
Add a Minecraft monitor
Uptime Kuma 1.x ships a built-in Minecraft Server monitor type. It uses the
Server List Ping protocol (the same ping the vanilla multiplayer list uses):
unauthenticated, so it works fine with ONLINE_MODE=FALSE /
ENFORCE_SECURE_PROFILE=FALSE. It reports latency, online/max players, and MOTD.
- Open
https://status.${BASE_DOMAIN}and log in (admin account created on first run). - + Add New Monitor.
- Monitor Type:
Minecraft Server. - Fill in one of the two probe targets below.
- Heartbeat Interval:
60s (fine for a friends' server). - Retries:
2, Retry Interval:30s — avoids flapping on a GC pause. - Save.
Two targets — add both
| Monitor | Server | Port | What it proves |
|---|---|---|---|
MC (internal) |
minecraft |
25565 |
The server process is up and accepting pings inside mcnet. |
MC (public) |
mc.${BASE_DOMAIN} |
25565 |
The full path works: DNS → host firewall → docker port publish → server. |
The public monitor is the one that catches "I can't connect" outages — firewall, DNS, or an unpublished port all show red here while the internal monitor stays green. Run both to tell server down apart from path broken.
Internal
minecraftresolves because uptime-kuma is onmcnet(the container name is the hostname). It is not routed through caddy — caddy only fronts HTTP vhosts, and MC is raw TCP. Do not point the monitor atcaddyor anystatus.alias.
Notes
- The Minecraft monitor pings TCP
25565; it does not check Simple Voice Chat (24454/udp). Add a separate TCP Port monitor against UDP if you want voice coverage — but Kuma's TCP monitor is TCP-only, so UDP voice has no clean probe; rely on the player report instead. - Put both MC monitors on the public status page (Settings → Status Pages) so guests can self-check before pinging you.
- Optional companion HTTP monitors for the web stack:
https://auth.${BASE_DOMAIN},https://distribution.${BASE_DOMAIN},https://${BASE_DOMAIN}— a reddistribution.here explains client mod-mismatch join failures.