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

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

@louislam

1. Kindly validate if I understand the transition between Monitor Statuses (PENDING, UP, DOWN) correctly
2. 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

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 Unit Testing monitors with Testcontainers #4451, but currently I have not found the time to investigate this.

@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