[GH-ISSUE #2040] [Feature request] add random times to checks #1267

New issue

Open

opened 2026-03-02 02:22:15 +03:00 by kerem · 3 comments

kerem commented

2026-03-02 02:22:15 +03:00

Owner

Originally created by @P6g9YHK6 on GitHub (Oct 22, 2024).
Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/2040

Is your feature request related to a problem? Please describe.
currently i have some checks that will when executed on multiple hosts at the same time will simply DDOS either a hypervisor or even a remote website/endpoint.
this also apply to a speed test that would require that each hosts test the speed at separate times.

Describe the solution you'd like
another field when creating a check that will ask for a range of time to be added before executing the check automatically
this should also apply on "run check now" when called from either the site or the client but not on the agent this is why another value is needed or would need to be calculated separately for when "run check now" is used not on the agent

Describe alternatives you've considered
all problematic scripts would have to have a snippet {{randomdelay}} and sleep them for the range set in a var
low priority stuff but i though it should still be opened

Additional context

Originally created by @P6g9YHK6 on GitHub (Oct 22, 2024). Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/2040 **Is your feature request related to a problem? Please describe.** currently i have some checks that will when executed on multiple hosts at the same time will simply DDOS either a hypervisor or even a remote website/endpoint. this also apply to a speed test that would require that each hosts test the speed at separate times. **Describe the solution you'd like** another field when creating a check that will ask for a range of time to be added before executing the check automatically this should also apply on "run check now" when called from either the site or the client but not on the agent this is why another value is needed or would need to be calculated separately for when "run check now" is used not on the agent **Describe alternatives you've considered** all problematic scripts would have to have a snippet {{randomdelay}} and sleep them for the range set in a var low priority stuff but i though it should still be opened **Additional context** ![image](https://github.com/user-attachments/assets/19bbb111-c831-49b8-9011-22a117664879) ![image](https://github.com/user-attachments/assets/54ca24b2-a72e-46ca-aae1-3c9b99148326) ![image](https://github.com/user-attachments/assets/92507ced-017c-4882-be30-6686414af088)

kerem commented

2026-03-02 02:22:15 +03:00

Author

Owner

@P6g9YHK6 commented on GitHub (Oct 28, 2024):

found an exemple in eset of an imprementation of this for the same reasons

</html>

<html> > | Random delay interval setting is available for Scheduled type triggers. It defines the range of maximum delay for task execution. Randomizing can prevent overloading the server. > -- | -- > > >

@P6g9YHK6 commented on GitHub (Oct 28, 2024): found an exemple in eset of an imprementation of this for the same reasons ![image](https://github.com/user-attachments/assets/6d090c85-c1f0-4eaa-afb4-b0d46264d6e8) > </html> > </body> >  > <body> <html> > | Random delay interval setting is available for Scheduled type triggers. It defines the range of maximum delay for task execution. Randomizing can prevent overloading the server. > -- | -- > > >

kerem commented

2026-03-02 02:22:15 +03:00

Author

Owner

@ccarney16 commented on GitHub (Dec 9, 2024):

I like this idea, though I'd much prefer something similar to ansible/ci systems where you can specify how many concurrent jobs can be run at the same time. So perhaps something like "Max Concurrent: " instead of a random delay would be better.

@ccarney16 commented on GitHub (Dec 9, 2024): I like this idea, though I'd much prefer something similar to ansible/ci systems where you can specify how many concurrent jobs can be run at the same time. So perhaps something like "Max Concurrent: <num>" instead of a random delay would be better.

kerem commented

2026-03-02 02:22:15 +03:00

Author

Owner

@wh1te909 commented on GitHub (Mar 7, 2025):

partially implemented: https://docs.tacticalrmm.com/functions/settings_override/#configuring-agent-check-jitter
this is until we can get it into the UI. it currently only applies to the agent's own scheduler, so manually triggering check runs from the UI will run immediately

@wh1te909 commented on GitHub (Mar 7, 2025): partially implemented: https://docs.tacticalrmm.com/functions/settings_override/#configuring-agent-check-jitter this is until we can get it into the UI. it currently only applies to the agent's own scheduler, so manually triggering check runs from the UI will run immediately