starred/uptime-kuma

Fork 0

mirror of https://github.com/louislam/uptime-kuma.git synced 2026-03-02 22:57:00 -05:00

option to accept informational messages or third status for push monitors #3827

New issue

Open

opened 2026-02-28 03:42:12 -05:00 by deekerman · 11 comments

deekerman commented

2026-02-28 03:42:12 -05:00

Owner

Originally created by @ww7 on GitHub (Dec 11, 2024).

⚠️ Please verify that this question has NOT been raised before.

I checked and didn't find similar issue

🛡️ Security Policy

I agree to have read this project Security Policy

📝 Describe your problem

I'm monitoring free disk space on many nodes and using a single Push monitor.

After the first down event triggered, Kuma not accept additional down events and waiting for up.

I need some workaround to push additional notifications when it already at down. Like:

Status | DateTime |
Down | 00:12:34 | overused: 132(dev-testing):93%, 201(labelstudio):95%, 432(gitlab-runner2):92%
Down | 00:12:56 | overused: 100(prod):91%

It can be an option of Push monitor to accept additional down events.
Or/also middle status like inform.

📝 Error Message(s) or Log

No response

🐻 Uptime-Kuma Version

2 beta

💻 Operating System and Arch

Ubuntu 24.04 x86

🌐 Browser

Firefox

🖥️ Deployment Environment

Runtime: Docker

Originally created by @ww7 on GitHub (Dec 11, 2024). ### ⚠️ Please verify that this question has NOT been raised before. - [X] I checked and didn't find similar issue ### 🛡️ Security Policy - [X] I agree to have read this project [Security Policy](https://github.com/louislam/uptime-kuma/security/policy) ### 📝 Describe your problem I'm monitoring free disk space on many nodes and using a single Push monitor. After the first `down` event triggered, Kuma not accept additional `down` events and waiting for `up`. I need some workaround to push additional notifications when it already at `down`. Like: > Status | DateTime | > Down | 00:12:34 | overused: 132(dev-testing):93%, 201(labelstudio):95%, 432(gitlab-runner2):92% > Down | 00:12:56 | overused: 100(prod):91% It can be an option of Push monitor to accept additional down events. Or/also middle `status` like `inform`. ### 📝 Error Message(s) or Log _No response_ ### 🐻 Uptime-Kuma Version 2 beta ### 💻 Operating System and Arch Ubuntu 24.04 x86 ### 🌐 Browser Firefox ### 🖥️ Deployment Environment Runtime: Docker

deekerman added the

feature-request

A:monitor

type:enhance-existing

labels

2026-02-28 03:42:12 -05:00

deekerman commented

2026-02-28 03:42:14 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Dec 11, 2024):

I'm monitoring [..] many nodes and using a single Push monitor

Please only use one monitor per thing that you want to monitor instead.

@CommanderStorm commented on GitHub (Dec 11, 2024): > I'm monitoring [..] many nodes and using a single Push monitor Please only use one monitor per thing that you want to monitor instead.

deekerman commented

2026-02-28 03:42:15 -05:00

Author

Owner

@ww7 commented on GitHub (Dec 11, 2024):

I'm sure and believe my request is reasonable.

I already have many monitors.

Please only use one monitor per thing that you want to monitor instead.

With 30+ nodes (monitorings) it will be difficult to manage, hard to script, and Kuma database overuse.

I already use complex monitoring over the whole Proxmox Cluster via API with a single script and single Push monitor:

#!/usr/bin/env bash
set -e
script_dir="$( cd "$( dirname "$0" )" && pwd )"
cd $script_dir && source .env

threshold=90

log_file="pve-cluster-monitor-disks.log"
overused_vms=""

vm_list=$(curl -k -s -H "$token_header" "$api_url/cluster/resources?type=vm" \
  | jq -r '.data[] | [.node, .type, (.vmid|tostring), .name] | @tsv')

while IFS=$'\t' read -r node type vmid vmname; do
  
  disk_usage=$(curl -k -s -H "$token_header" "$api_url/nodes/$node/$type/$vmid/status/current" \
    | jq -r '.data | (.disk / .maxdisk * 100 | floor)')

  if (( disk_usage > threshold )); then
      overused_vms="$overused_vms, $vmid($vmname):${disk_usage}%"
      message="$(date +"%Y-%m-%d %H-%M"): VMID $vmid ($vmname) current disk usage ${disk_usage}% exceeds threshold $threshold%"
      echo $message >> "$log_file"
  fi
done <<< "$vm_list"

push() {
  local status=$1
  local message=$2
  message=$(echo "$message" | sed 's/%/%25/g; s/ /%20/g; s/</%3C/g; s/>/%3E/g')
  local ttl=$(ping -c 1 "$cluster_host" | tail -1 | cut -d '/' -f 5)
  curl -s -X POST "$push_url_vms_disk?status=$status&msg=$message&ping=$ttl" > /dev/null 2>&1
}

if [ -z "$overused_vms" ]; then 
  message="All VMs disk space is OK (threshold >${threshold}%)"
  push "up" "$message"
else
  overused_vms="${overused_vms#,}"
  message="Space overused (>${threshold}%):$overused_vms"
  push "down" "$message"
fi

Only missing easy, straightforward way to be perfect.
Sure I can send notifications from the script, but will love to log all events with Kuma.

@ww7 commented on GitHub (Dec 11, 2024): I'm sure and believe my request is reasonable. I already have many monitors. > Please only use one monitor per thing that you want to monitor instead. With 30+ nodes (monitorings) it will be difficult to manage, hard to script, and Kuma database overuse. I already use complex monitoring over the whole Proxmox Cluster via API with a single script and single Push monitor: ```sh #!/usr/bin/env bash set -e script_dir="$( cd "$( dirname "$0" )" && pwd )" cd $script_dir && source .env threshold=90 log_file="pve-cluster-monitor-disks.log" overused_vms="" vm_list=$(curl -k -s -H "$token_header" "$api_url/cluster/resources?type=vm" \ | jq -r '.data[] | [.node, .type, (.vmid|tostring), .name] | @tsv') while IFS=$'\t' read -r node type vmid vmname; do disk_usage=$(curl -k -s -H "$token_header" "$api_url/nodes/$node/$type/$vmid/status/current" \ | jq -r '.data | (.disk / .maxdisk * 100 | floor)') if (( disk_usage > threshold )); then overused_vms="$overused_vms, $vmid($vmname):${disk_usage}%" message="$(date +"%Y-%m-%d %H-%M"): VMID $vmid ($vmname) current disk usage ${disk_usage}% exceeds threshold $threshold%" echo $message >> "$log_file" fi done <<< "$vm_list" push() { local status=$1 local message=$2 message=$(echo "$message" | sed 's/%/%25/g; s/ /%20/g; s/</%3C/g; s/>/%3E/g') local ttl=$(ping -c 1 "$cluster_host" | tail -1 | cut -d '/' -f 5) curl -s -X POST "$push_url_vms_disk?status=$status&msg=$message&ping=$ttl" > /dev/null 2>&1 } if [ -z "$overused_vms" ]; then message="All VMs disk space is OK (threshold >${threshold}%)" push "up" "$message" else overused_vms="${overused_vms#,}" message="Space overused (>${threshold}%):$overused_vms" push "down" "$message" fi ``` Only missing easy, straightforward way to be perfect. Sure I can send notifications from the script, but will love to log all events with Kuma.

deekerman commented

2026-02-28 03:42:15 -05:00

Author

Owner

@github-actions[bot] commented on GitHub (Mar 18, 2025):

We are clearing up our old help-issues and your issue has been open for 60 days with no activity.
If no comment is made and the stale label is not removed, this issue will be closed in 7 days.

@github-actions[bot] commented on GitHub (Mar 18, 2025): We are clearing up our old `help`-issues and your issue has been open for 60 days with no activity. If no comment is made and the stale label is not removed, this issue will be closed in 7 days.

deekerman commented

2026-02-28 03:42:16 -05:00

Author

Owner

@ww7 commented on GitHub (Mar 18, 2025):

Any chance to have some custom informational status?

Without changing of up or down status, just for recording and notifications about current state.

@ww7 commented on GitHub (Mar 18, 2025): Any chance to have some custom informational status? Without changing of `up` or `down` status, just for recording and notifications about current state.

deekerman commented

2026-02-28 03:42:16 -05:00

Author

Owner

@github-actions[bot] commented on GitHub (May 17, 2025):

We are clearing up our old help-issues and your issue has been open for 60 days with no activity.
If no comment is made and the stale label is not removed, this issue will be closed in 7 days.

@github-actions[bot] commented on GitHub (May 17, 2025): We are clearing up our old `help`-issues and your issue has been open for 60 days with no activity. If no comment is made and the stale label is not removed, this issue will be closed in 7 days.

deekerman commented

2026-02-28 03:42:16 -05:00

Author

Owner

@CommanderStorm commented on GitHub (May 17, 2025):

Any chance to have some custom informational status?

No other monitor has informational satuses and this does not really fit into our model of important and not important events.

@CommanderStorm commented on GitHub (May 17, 2025): > Any chance to have some custom informational status? No other monitor has informational satuses and this does not really fit into our model of important and not important events.

deekerman commented

2026-02-28 03:42:16 -05:00

Author

Owner

@ww7 commented on GitHub (May 18, 2025):

@CommanderStorm
Request means not unimportant events, but the ability to receive additional alerts when monitor down, possibly with different messages.

@ww7 commented on GitHub (May 18, 2025): @CommanderStorm Request means not unimportant events, but the ability to receive additional alerts when monitor down, possibly with different messages.

deekerman commented

2026-02-28 03:42:16 -05:00

Author

Owner

@CommanderStorm commented on GitHub (May 18, 2025):

Actually, your core issue is that how you would like to run things (1 monotor = n things being monitored) does not work with how we recomend to do things (1 monotor = 1 thing being monitored).

If you just split those things, you won't have a problem using a single push monitor for this is not recomened.

@CommanderStorm commented on GitHub (May 18, 2025): Actually, your core issue is that how you would like to run things (1 monotor = n things being monitored) does not work with how we recomend to do things (1 monotor = 1 thing being monitored). If you just split those things, you won't have a problem using a single push monitor for this is not recomened.

deekerman commented

2026-02-28 03:42:16 -05:00

Author

Owner

@ww7 commented on GitHub (May 19, 2025):

No, request indeed about the ability to receive status updates and new messages additionally either if monitor already in same state (up or down).

@ww7 commented on GitHub (May 19, 2025): No, request indeed about the ability to receive status updates and new messages additionally either if monitor already in same state (up or down).

deekerman commented

2026-02-28 03:42:16 -05:00

Author

Owner

@nneul commented on GitHub (Jul 27, 2025):

I think rephrasing this feature request as:

[X] change in push message content should be triggered as new event

Even ignoring the "multiple monitors" aspect - being able to "update the down or up status" without toggling from down/up/down would be useful if the push monitor is "partial" and reporting something more than just a binary state. i.e. think if you were using it to report a disk space error, it would be good to have the message update.

Note in MY use case, I don't care as much about the repeat notification, but I do want to be able to see the latest message on the dashboard. Right now, that message update is only visible during a state change.

@nneul commented on GitHub (Jul 27, 2025): I think rephrasing this feature request as: [X] change in push message content should be triggered as new event Even ignoring the "multiple monitors" aspect - being able to "update the down or up status" without toggling from down/up/down would be useful if the push monitor is "partial" and reporting something more than just a binary state. i.e. think if you were using it to report a disk space error, it would be good to have the message update. Note in MY use case, I don't care as much about the repeat notification, but I do want to be able to see the latest message on the dashboard. Right now, that message update is only visible during a state change.

deekerman commented

2026-02-28 03:42:16 -05:00

Author

Owner

@ww7 commented on GitHub (Jul 28, 2025):

I think rephrasing this feature request as:

Indeed.
On my request within event message update asking for optional notification.

@ww7 commented on GitHub (Jul 28, 2025): > I think rephrasing this feature request as: Indeed. On my request within event message update asking for optional notification.