01 / THE ROLE
In this lab.
Uptime Kuma was tested and promoted into a dedicated VM, with local Docker storage and SQLite state. Its current documented role is production ping monitoring organised into groups, with notifications routed through n8n. It complements Zabbix rather than replacing the primary monitoring requirements.
02 / THE CONNECTIONS
Follow the flow.
- STEP 01Production targets
- STEP 02Availability probes
- STEP 03Kuma history
- STEP 04Notification route
03 / How it works
How it works.
The monitor measures the configured condition from the Kuma environment. A ping target tells me about network reachability from that vantage point; it does not establish that an application or its database works. Grouping helps presentation without requiring duplicate notifications at both target and group level.
04 / Persistent data & recovery
Persistent data & recovery.
The persistent application volume contains its SQLite-backed state. Migration and recovery need a consistent copy and the relevant configuration. VM-backup inclusion is part of operational onboarding, and a successful restore still needs to be checked rather than inferred from a schedule.
05 / How to check it
How to check it.
Validate representative failure and recovery behaviour, the notification route and recent monitor results. Zabbix also monitors the Kuma application. A successful Kuma probe cannot prove the independent alert-delivery path is available.
06 / Decisions & limits
Decisions & limits.
Running probes outside the main monitoring host reduces one dependency, but notification delivery still has its own services and network dependencies. Independence must be described per path rather than claimed for the entire monitoring system.