louislam/uptime-kuma

📑 I have found these related issues/pull requests I could not find related issues. 🛡️ Security Policy I have read and agree to Uptime Kuma's Security Policy. 📝 Description I have a group that contains monitors for virtual machines. I pause the whole group Kill all virtual machines for updates Uptime kuma starts sending alerts that the individual VMs are down Group appears paused, but not the individual VMs under that group 👟 Reproduction steps Pause a group Kill the systems under the group See that uptime kuma complains about the killed systems 👀 Expected behavior I expect all monitors under the group to be paused as well. 😓 Actual Behavior Alerts about killed VMs. 🐻 Uptime-Kuma Version 2.2.1 💻 Operating System and Arch AlmaLinux 10 with Docker 🌐 Browser Firefox 149 🖥️ Deployment Environment Runtime Environment: Docker: Version 29.3.1 (ce edition) Docker Compose: Version 5.1.1 Database: No idea, whatever came with the docker container? D

📑 I have found these related issues/pull requests This has been already suggested here: #6256 (comment) by @cyril59310 in the discussion of the PR of @TheBestPartOfMe to implement #6196. 🔖 Feature description On the dashboard page, one can drag-and-drop a monitor (or group of monitors) into a group. But once the monitor is in a group, it cannot be dragged out on the top of the hierarchy (one needs to go to the monitor, edit, monitor group, select, save). ✔️ Solution When dragging a monitor either... Right at the top of the monitors list Right at the bottom of the monitors list Also maybe, in-between any groups Then, dragged the monitor should be unlinked from the group it was, and be considered outside of any group I would suggest a big green bar when hovering in a position that would result in un-parenting the element (same color as the dotted line surrounding a group when hovering the dragged element to drop). Also, note that since elements are automatically sorted alpha

📑 I have found these related issues/pull requests This issue follows a discussion here: #7042 (comment) 🔖 Feature description Right now, upon new maintenance creation, start datetime and end datetime are not linked whatsoever: it's even possible to set a end time which predates the start time without raising any error. All of this could be slightly smarter. ✔️ Solution I see this issue in three parts: The end datetime could be modified dynamically upon modification of start datetime: When start date is changed manually, use the currently selected duration to re-compute the end date accordingly. For instance: Initial situation: Start date set to 24/02/2026 01:00 Duration set to 1 hour Implies end date set to 24/02/2026 02:00 Change: Start date changed to 24/02/2026 03:00 Provokes setting end date to 24/02/2026 04:00 The only exception to that should be when the user has already modified the end date manually. In that case, just select the matching duration, if appli

📑 I have found these related issues/pull requests . 🛡️ Security Policy I have read and agree to Uptime Kuma's Security Policy. 📝 Description Hi after updating to 2.1.0 my Uptime Kuma after few minutes went from 20% performance (CPU RAM) to 100% performance, before update i dont have any issue same settings i have before update. 👟 Reproduction steps reboot :D 👀 Expected behavior . 😓 Actual Behavior . 🐻 Uptime-Kuma Version 2.1.0 💻 Operating System and Arch Debian 🌐 Browser . 🖥️ Deployment Environment . 📝 Relevant log output journalctl -u uptime-kuma -n 200 --no-pager -- Journal begins at Thu 2026-01-29 15:29:32 CET, ends at Sun 2026-02-08 14:19:56 CET. -- Feb 08 14:02:23 UptimeKuma npm[169]: ============================================================ | Interval: 20 seconds | Type: real-browser | Down Count: 0 | Resend Interval: 0 Feb 08 14:02:43 UptimeKuma npm[169]: 2026-02-08T14:02:43+01:00 [MONITOR] WARN: Monitor #30 'Dzuriš.Dev': Failing: pa