Skip to content
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

Dependent check #2335

Closed
1 task done
gheydon opened this issue Nov 20, 2022 · 2 comments
Closed
1 task done

Dependent check #2335

gheydon opened this issue Nov 20, 2022 · 2 comments
Labels
feature-request Request for new features to be added

Comments

@gheydon
Copy link

gheydon commented Nov 20, 2022

⚠️ Please verify that this feature request has NOT been suggested before.

  • I checked and didn't find similar feature request

🏷️ Feature Request Type

Other

🔖 Feature description

I have set up uptime kuma on the internal network as I have both internal and external servers to check. (More internal servers but over VPN)

I have a check to see if the current internet connection is up but in the case where this is down I do not want to check any dependent services as they are going to fail.

A more generic example if that I have 5 servers A B C D and E and if server A is down B C and D are also going to report as down even it just fixing Server A is going to resolve the issue with B C and D. So in this case I do not need to know about B C and D.

✔️ Solution

I think adding a dependency field on the monitor setup, so in may case above for B, C and D would have a dependency on Monitor A. Also a second field which will not set a timeout so that it can only check B, C and D if A has been checked within x amount of time.

❓ Alternatives

No response

📝 Additional Context

No response

@gheydon gheydon added the feature-request Request for new features to be added label Nov 20, 2022
@koen20
Copy link
Contributor

koen20 commented Nov 20, 2022

Someone opened a pull request #1236 which adds this feature.
This is a duplicate of #1089

@CommanderStorm
Copy link
Collaborator

@gheydon
We are consolidating duplicate issues a bit to make issue management eazier.
I think, we should track this issue in #1089 as there is no functional difference (maybe just small naming differences, but nothing that would require a different issue imo)
=> I am going to close this as a duplicate

@CommanderStorm CommanderStorm closed this as not planned Won't fix, can't repro, duplicate, stale Dec 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request Request for new features to be added
Projects
None yet
Development

No branches or pull requests

3 participants