You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think that the heartbeat feature does not work correctly with push monitors.
We can take this use case:
Monitor settings:
Hearbeat interval: 900
Retries: 5
Heartbeat Retry Interval: 60
Use cases:
When everything is working my device push an "ok" status every 900 seconds and uptime if full green. It's ok.
If my device goes down my script does not send any "ok" status so uptime turn into orange with "No heartbeat in the time window" before going to red as expected. It's ok.
But, if my device explicitly push a "down" status with a script then the heartbeat stuff is still triggered so status bar shows something like this:
ok (green)
ok (green)
ok (green)
down (red) (this is my intentional down push thanks to the script)
pending (orange) (No heartbeat in the time window)
pending (orange) (No heartbeat in the time window)
pending (orange) (No heartbeat in the time window)
pending (orange) (No heartbeat in the time window)
pending (orange) (No heartbeat in the time window)
down (red) (No heartbeat in the time window)
And this use case is not correct because for me, we should consider the intentional down push to be a valid heartbeat, in fact, the device just pushed a DOWN status so the device is not "dead". In the case of the push monitor we should trigger the heartbeat countdown only in case we do have any URL push (OK or DOWN) during the specified period.
I hope my explanation to be clear :)
Thanks
π Reproduction steps
See the use case given in description.
π Expected behavior
Do no trigger the "Heartbeat pending" stage if monitor is push type and device explicitly pushed a DOWN status.
π Actual Behavior
The "heartbeat pending" stage is triggered after an explicit DOWN status push.
π» Uptime-Kuma Version
1.23.15
π» Operating System and Arch
Docker compose stack
π Browser
Safari
π₯οΈ Deployment Environment
Runtime: Docker
Database: sqlite
Filesystem used to store the database on: Docker bing mount (Debian host)
number of monitors: 20
π Relevant log output
The text was updated successfully, but these errors were encountered:
π I have found these related issues/pull requests
No related issue found.
π‘οΈ Security Policy
Description
I think that the heartbeat feature does not work correctly with push monitors.
We can take this use case:
Monitor settings:
Use cases:
And this use case is not correct because for me, we should consider the intentional down push to be a valid heartbeat, in fact, the device just pushed a DOWN status so the device is not "dead". In the case of the push monitor we should trigger the heartbeat countdown only in case we do have any URL push (OK or DOWN) during the specified period.
I hope my explanation to be clear :)
Thanks
π Reproduction steps
See the use case given in description.
π Expected behavior
Do no trigger the "Heartbeat pending" stage if monitor is push type and device explicitly pushed a DOWN status.
π Actual Behavior
The "heartbeat pending" stage is triggered after an explicit DOWN status push.
π» Uptime-Kuma Version
1.23.15
π» Operating System and Arch
Docker compose stack
π Browser
Safari
π₯οΈ Deployment Environment
π Relevant log output
The text was updated successfully, but these errors were encountered: