Episode 16: Kuma alerts sorted by rules, a local agent and a script

ops-readonly gets kuma_alerts (host export kuma-export.py, one more read-only
mount). kuma-triage.py sorts the same data without a model. Flow H runs the
agent with skill alert-triage.md. Flow B: one open incident per monitor, an
UP closes all of them, titles name start and end and stay under Outline's
limit. B and D accept Kuma only with a header token. Monitoring notes: ntfy
rejects Kuma messages for monitors without a URL, resend for long outages.

monitoring/README.md

@@ -159,3 +159,20 @@ retry), the UP alert follows about a minute after the container is healthy.
 - `louislam/uptime-kuma:1` is the 1.x line (1.23.17 at recording time).
   2.x exists (2.5.3) and migrates the database on first start. Pin what you
   test, upgrade on purpose, not by `docker compose pull`.
+
+
+## What episode 16 found in this setup
+
+- **ntfy rejects Kuma's message for monitors without a URL.** Ping, port,
+  group and push monitors have no URL; Kuma still adds a "view" button and
+  ntfy answers `400 parameter 'url' is required for action 'view'`. The alert
+  never arrives, only the Kuma log shows it. Give those monitors a URL (any
+  page, for example the status page); in the Kuma database that is the `url`
+  column, the edit form hides it for these types.
+- **Kuma only alerts on a change.** A monitor that stays down is announced
+  once. Set "Resend Notification if Down X times consecutively" (for a 60 s
+  interval, 60 means once an hour), otherwise a twelve day outage looks
+  exactly like a one minute one.
+- **Every Kuma restart announces every down monitor again.** After a restart
+  the first beat is PENDING, the next DOWN counts as a change. Anything that
+  opens tickets from Kuma must skip a DOWN for a monitor that is already open.