starred/uptime-kuma

Fork 0

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

Lower heartbeat interval when monitor is `DOWN`? #2786

New issue

Closed

opened 2026-02-28 03:07:12 -05:00 by deekerman · 7 comments

deekerman commented

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

Owner

Originally created by @Vincent-HD on GitHub (Nov 13, 2023).

⚠️ Please verify that this bug 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 would like the possibility to lower the heartbeat interval when a monitor is marked as DOWN.
For example, here I have an Interval of 30 min betweens checks and 60 sec x 3 on pending. But as soon as it is marked as DOWN, it checks every 30 min again, can we change that behaviour?

It's useful if I don't want to “spam” our websites with checks, but I want to be able to be notified as soon as I want when a monitor is back up

So it would be, for example:

Check every 30 min if UP
Check every 30 sec if PENDING and max 3 times
Check every 5 min if DOWN

Thank you 👍

📝 Error Message(s) or Log

No response

🐻 Uptime-Kuma Version

1.23.1

💻 Operating System and Arch

Ubuntu 20.04.5

🌐 Browser

Vivaldi 6.4.3160.42

🐋 Docker Version

23.0.0

🟩 NodeJS Version

No response

Originally created by @Vincent-HD on GitHub (Nov 13, 2023). ### ⚠️ Please verify that this bug 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 would like the possibility to lower the heartbeat interval when a monitor is marked as `DOWN`. For example, here I have an Interval of 30 min betweens checks and 60 sec x 3 on pending. But as soon as it is marked as `DOWN`, it checks every 30 min again, can we change that behaviour? It's useful if I don't want to “spam” our websites with checks, but I want to be able to be notified as soon as I want when a monitor is back up So it would be, for example: - Check every 30 min if `UP` - Check every 30 sec if `PENDING` and max 3 times - Check every 5 min if `DOWN` Thank you 👍 ### 📝 Error Message(s) or Log _No response_ ### 🐻 Uptime-Kuma Version 1.23.1 ### 💻 Operating System and Arch Ubuntu 20.04.5 ### 🌐 Browser Vivaldi 6.4.3160.42 ### 🐋 Docker Version 23.0.0 ### 🟩 NodeJS Version _No response_

deekerman

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

closed this issue
added the
feature-request

A:monitor

type:enhance-existing

good first issue
labels

deekerman commented

2026-02-28 03:07:17 -05:00

Author

Owner

@chakflying commented on GitHub (Nov 13, 2023):

Interesting, I think it would be more reasonable if the retry interval applies to down status as well.

@chakflying commented on GitHub (Nov 13, 2023): Interesting, I think it would be more reasonable if the retry interval applies to down status as well.

deekerman commented

2026-02-28 03:07:17 -05:00

Author

Owner

@louislam commented on GitHub (Nov 13, 2023):

Actually true, don't know why didn't think about it.

@louislam commented on GitHub (Nov 13, 2023): Actually true, don't know why didn't think about it.

deekerman commented

2026-02-28 03:07:17 -05:00

Author

Owner

@doitlikejustin commented on GitHub (Jan 4, 2024):

+1 for this!

@doitlikejustin commented on GitHub (Jan 4, 2024): +1 for this!

deekerman commented

2026-02-28 03:07:17 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Jan 4, 2024):

@doitlikejustin
Please refrain from posting +1 / requests for updates things on issues, as this makes issue-management harder.
Issues are for discussing what needs to be done how by whom.
We use 👍🏻 on issues to prioritise work, as always: Pull Requests welcome.

@CommanderStorm commented on GitHub (Jan 4, 2024): @doitlikejustin Please refrain from posting `+1` / requests for updates things on issues, as this makes issue-management harder. Issues are for discussing **what needs to be done how by whom**. [We use 👍🏻 on issues to prioritise work](https://github.com/louislam/uptime-kuma/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc), as always: [Pull Requests](https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md) welcome.

deekerman commented

2026-02-28 03:07:17 -05:00

Author

Owner

@neelbhanushali commented on GitHub (Feb 11, 2024):

@louislam

Kindly validate if I understand the transition between Monitor Statuses (PENDING, UP, DOWN) correctly
If my understanding about the transition is correct, also validate the requirement by @Vincent-HD (OP)
- OP wants to change the behavior where the next action taken after DOWN status is Hit every Heartbeat Interval
- Instead, there should be another input that controls transitioning from DOWN to UP; similar to how Heartbeat Retry Interval controls transitioning from PENDING to UP after a failure.

Flowchart

flowchart TD
    Start(Start => `!hasPreviousBeat`)
    P2(((Pending)))
    P(((Pending)))
    U(((Up)))
    D(((Down)))
    HI[Hit every `Heartbeat Interval`]
    HRI[Hit every `Heartbeat Retry Interval`]
    Reset_R[Reset `Retries` counter]
    isUp{Check successfull?}
    isMaxRetry{`Retries`-limit reached?}
    

    Start --> P2
    P2 --> HI
    HI --> isUp

    isUp --> |No| isMaxRetry
    isUp --> |Yes| Reset_R
    Reset_R --> U

    isMaxRetry --> |No| P
    P --> HRI
    isMaxRetry --> |Yes| D

    HRI --> isUp
    D --> HI
    U --> HI

Flow Chart Details

Monitor Status are circle (PENDING, UP, DOWN)
Rectangles are actions performed by Uptime Kuma
Rhombuses are checks

@neelbhanushali commented on GitHub (Feb 11, 2024): @louislam 1. Kindly validate if I understand the transition between Monitor Statuses (`PENDING`, `UP`, `DOWN`) correctly 1. If my understanding about the transition is correct, also validate the requirement by @Vincent-HD (`OP`) - `OP` wants to change the behavior where the next action taken after <code>DOWN</code> status is <code>Hit every `Heartbeat Interval`</code> - Instead, there should be another input that controls transitioning from <code>DOWN</code> to <code>UP</code>; similar to how <code>Heartbeat Retry Interval</code> controls transitioning from <code>PENDING</code> to <code>UP</code> after a failure. <hr> ### Flowchart ```mermaid flowchart TD Start(Start => `!hasPreviousBeat`) P2(((Pending))) P(((Pending))) U(((Up))) D(((Down))) HI[Hit every `Heartbeat Interval`] HRI[Hit every `Heartbeat Retry Interval`] Reset_R[Reset `Retries` counter] isUp{Check successfull?} isMaxRetry{`Retries`-limit reached?} Start --> P2 P2 --> HI HI --> isUp isUp --> |No| isMaxRetry isUp --> |Yes| Reset_R Reset_R --> U isMaxRetry --> |No| P P --> HRI isMaxRetry --> |Yes| D HRI --> isUp D --> HI U --> HI ``` <details><summary>Flow Chart Details</summary> <p> 1. Monitor Status are circle (`PENDING`, `UP`, `DOWN`) 1. Rectangles are actions performed by Uptime Kuma 1. Rhombuses are checks </p> </details>

deekerman commented

2026-02-28 03:07:18 -05:00

Author

Owner

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

I have edited the diagram¹ to hopefully clear the question a bit up (inlining, clarifying).

In terms of correctness of the diagram:

above diagram does not cover is the Upside Down Mode => this just reverses what is considered successful
I would need to look into the code if the Retries-counter is reset on DOWN

In terms of proposal:

Instead, there should be another input that controls transitioning from DOWN to UP; similar to how Heartbeat Retry Interval controls transitioning from PENDING to UP after a failure.

Reusing the Heartbeat Retry Interval for DOWN beats (as suggested by @chakflying) seems intuitive enough. I don't think another setting needs to be added.
In any case, I think such adjustments might benefit if made after all monitors have been moved into their file (i.e. from monitor.js to monitor-types/*.js). Currently, reasoning about this is quite complicated, as can be seen by your comment.
⇒ If somebody wants to extract one of the monitors and test that it still works, our contribution guide can be found here
A thing why I am also not quite confident in this area is that the state model is largely untested. Testing of monitors (as closely related to the state mechanism) is something that we might be able to achieve via https://github.com/louislam/uptime-kuma/pull/4451, but currently I have not found the time to investigate this.

The ability to have mermaid diagrams is very handy. ❤️ ↩︎

@CommanderStorm commented on GitHub (Feb 11, 2024): I have edited the diagram[^1] to hopefully clear the question a bit up (inlining, clarifying). In terms of correctness of the diagram: - above diagram does not cover is the `Upside Down Mode` => this just reverses what is considered successful - I would need to look into the code if the `Retries`-counter is reset on `DOWN` In terms of proposal: - > Instead, there should be another input that controls transitioning from <code>DOWN</code> to <code>UP</code>; similar to how <code>Heartbeat Retry Interval</code> controls transitioning from <code>PENDING</code> to <code>UP</code> after a failure. Reusing the `Heartbeat Retry Interval` for `DOWN` beats (as suggested by @chakflying) seems intuitive enough. I don't think another setting needs to be added. - In any case, I think such adjustments might benefit if made after all monitors have been moved into their file (i.e. from [`monitor.js`](https://github.com/louislam/uptime-kuma/blob/master/server/model/monitor.js) to [`monitor-types/*.js`](https://github.com/louislam/uptime-kuma/tree/master/server/monitor-types)). Currently, reasoning about this is quite complicated, as can be seen by your comment. ⇒ If somebody wants to extract one of the monitors and test that it still works, our [contribution guide can be found here](https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md) - A thing why I am also not quite confident in this area is that the state model is largely untested. Testing of monitors (as closely related to the state mechanism) is something that we might be able to achieve via https://github.com/louislam/uptime-kuma/pull/4451, but currently I have not found the time to investigate this. [^1]: The ability to have mermaid diagrams is very handy. ❤️

deekerman commented

2026-02-28 03:07:18 -05:00

Author

Owner

@neelbhanushali commented on GitHub (Feb 11, 2024):

@CommanderStorm

For the case @Vincent-HD mentioned, another field would be handly

It's useful if I don't want to “spam” our websites with checks, but I want to be able to be notified as soon as I want when a monitor is back up

So it would be, for example:

Check every 30 min if UP

Check every 30 sec if PENDING and max 3 times

Check every 5 min if DOWN

However, I totally agree

Reusing the Heartbeat Retry Interval for DOWN beats (as suggested by @chakflying) seems intuitive enough. I don't think another setting needs to be added.

Modifying @Vincent-HD case as below can be a win-win

Check every 30 min if UP

Check every 30 sec if PENDING and max 3 times

Check every 30 sec if DOWN

I'm willing to send a PR for this

I've gone through the Contribution Guidelines

I will be creating my branch from master and will be sending the PR back to master considering this as a new feature
Let me know if I need to switch to 1.23.X

@neelbhanushali commented on GitHub (Feb 11, 2024): @CommanderStorm For the case @Vincent-HD mentioned, another field would be handly > It's useful if I don't want to “spam” our websites with checks, but I want to be able to be notified as soon as I want when a monitor is back up > > So it would be, for example: > > * Check every 30 min if `UP` > * Check every 30 sec if `PENDING` and max 3 times > * Check every 5 min if `DOWN` However, I totally agree > * Reusing the `Heartbeat Retry Interval` for `DOWN` beats (as suggested by @chakflying) seems intuitive enough. I don't think another setting needs to be added. Modifying @Vincent-HD case as below can be a win-win > * Check every 30 min if `UP` > * Check every 30 sec if `PENDING` and max 3 times > * Check every 30 sec if `DOWN` <hr> I'm willing to send a PR for this I've gone through the [Contribution Guidelines](https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md#git-branches) I will be creating my branch from `master` and will be sending the PR back to `master` considering this as a new feature Let me know if I need to switch to `1.23.X`