-
-
Notifications
You must be signed in to change notification settings - Fork 5.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. Weβll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Push monitors' PENDING
-status not respecting retries
#4785
Comments
PENDING
-status not respecting retries
Where you are entirely correct is that the current way we are communicating this and how our retry/.. logic for this monitor works is super weird. Note As context
=> I don't know how setting a monitor to Tip If you want to use the retry logic in the current system, you should instead not send a push => let the push-monitor time out and go into the |
@CommanderStorm As I mentioned already, and others have mentioned before, letting something go into the pending state isn't really a solution if you have e.g. a job running once a day or are transitioning through a unit or container restart.
Everything else either delays notifications unnecessarily or creates too many false positives. It's not that different from something actively monitored by U-K, except that retries and retry periods just pass without actively retrying. |
You are explicitly setting it to
I am going to repeat myself as i am 5% unshure if my last communication was clear (no offense intended, just trying to not mis-communicate ^^) Tip If you want to use the retry logic in the current system, you should NOT send a push in the interval. |
π I have found these related issues/pull requests
DOWN
/UP
/...Β #1386π·οΈ Feature Request Type
API / automation options, Change to existing monitor
π Feature description
Sending
status=pending&msg=backup%20started
would immediately set the monitor to 'retry mode' without waiting for the usual period to expire.βοΈ Solution
There have been several mentions in the past.
Another example is monitoring processes that occasionally exit or need to be deliberately stopped but are expected to be restarted and become available within the retry period (think systemd unit).
Or a daily job where I generally expect
UP
once a day. When the job is being started I sendPENDING
, after which the monitor would go into retry mode and expect theUP
to arrive within say 1h instead of waiting a full day before raising a notification (think remote job dying or stalling or blocking somehow).β Alternatives
For the above-mentioned examples, I couldn't find alternatives short of implementing my own "pending logic" somehow. None of these would add a suitable event record to Uptime Kuma either.
π Additional Context
No response
The text was updated successfully, but these errors were encountered: