[GH-ISSUE #4566] [Feature]: Rate Limit the number of alerts that can be sent #2841

New issue

Open

opened 2026-02-27 03:05:44 +03:00 by kerem · 1 comment

kerem commented

2026-02-27 03:05:44 +03:00

Owner

Originally created by @MicLieg on GitHub (Apr 28, 2024).
Original GitHub issue: https://github.com/GameServerManagers/LinuxGSM/issues/4566

User story

As a server admin, i don't want to get spammed with alerts by a server that isn't starting correctly.

Game

All

Linux distro

Ubuntu 22.04

Command

command: monitor

Further information

Currently, if a server repeatedly crashes or can't start properly, when running the command ./gameserver monitor, LinuxGSM will send an alert that the server is offline (if alerts are turned on). Whilst this is generally very helpful to get notified of problems, it can cause a massive flood of alerts if the monitor command is set to run every 5 minutes, as suggested in the Docs.

I suggest either implementing a hard rate limit for a certain period of time, so that only a configurable number of alerts can be sent within a configurable period of time, or temporarily disabling alerts if the monitor command fails a configurable number of times in succession.

Originally created by @MicLieg on GitHub (Apr 28, 2024). Original GitHub issue: https://github.com/GameServerManagers/LinuxGSM/issues/4566 ### User story As a server admin, i don't want to get spammed with alerts by a server that isn't starting correctly. ### Game All ### Linux distro Ubuntu 22.04 ### Command command: monitor ### Further information Currently, if a server repeatedly crashes or can't start properly, when running the command `./gameserver monitor`, LinuxGSM will send an alert that the server is offline (if alerts are turned on). Whilst this is generally very helpful to get notified of problems, it can cause a massive flood of alerts if the monitor command is set to run every 5 minutes, as suggested in the [Docs](https://docs.linuxgsm.com/configuration/cronjobs#complete-example). I suggest either implementing a hard rate limit for a certain period of time, so that only a configurable number of alerts can be sent within a configurable period of time, or temporarily disabling alerts if the monitor command fails a configurable number of times in succession.

kerem added the

labels

2026-02-27 03:05:44 +03:00

kerem commented

2026-02-27 03:05:45 +03:00

Author

Owner

@irobot73 commented on GitHub (Jun 2, 2024):

Maybe a health check via Docker that we could then use the 'max_attempts' ala RESTART_POLICY (yeah, it's the server that's dorked...not the container)?

      # https://docs.docker.com/compose/compose-file/compose-file-v3/#restart_policy
      restart_policy:
        condition: on-failure
        delay: 10s #Default '5'
        max_attempts: 3

@irobot73 commented on GitHub (Jun 2, 2024): Maybe a health check via Docker that we could then use the 'max_attempts' ala RESTART_POLICY (yeah, it's the server that's dorked...not the container)? ``` # https://docs.docker.com/compose/compose-file/compose-file-v3/#restart_policy restart_policy: condition: on-failure delay: 10s #Default '5' max_attempts: 3 ```

kerem referenced this issue

2026-02-27 03:55:52 +03:00

[PR #2841] [MERGED] remove appinfo.vdf correctly #3806