Describe the bug
In Gatus v5.36.0, concurrency: 0 is documented as enabling unlimited concurrency.
However, ValidateAndSetConcurrencyDefaults treats any value less than or equal to zero as unspecified and replaces it with DefaultConcurrency, which is 3.
The debug log confirms this behavior:
[config.ValidateAndSetConcurrencyDefaults] Setting default concurrency to 3
This can prevent endpoints from reaching their alert failure threshold when several slow checks run simultaneously.
What do you see?
I monitor 15 local ICMP endpoints with an interval of 1 second. Each endpoint has email and custom alerts configured with a failure threshold of 2.
With:
concurrency: 0
Gatus logs:
[config.ValidateAndSetConcurrencyDefaults] Setting default concurrency to 3
When a network switch is rebooted, several ICMP checks take 10 seconds to time out. Because only three checks run concurrently, each affected endpoint records at most one failure before the switch comes back online.
Therefore, the configured failure threshold of 2 is not reached and no email or custom notification is generated.
What do you expect to see?
concurrency: 0 should enable unlimited concurrency, as stated in the documentation.
Gatus should preserve the configured value of 0 instead of replacing it with the default value of 3.
Alternatively, if unlimited concurrency is no longer supported, the documentation and configuration comments should be updated accordingly.
List the steps that must be taken to reproduce this issue
Configure Gatus v5.36.0 with multiple endpoints and concurrency: 0:
concurrency: 0
alerting:
custom:
url: "https://example.invalid/notification"
default-alert:
failure-threshold: 2
success-threshold: 2
send-on-resolved: true
endpoints:
Version
v5.36.0
Additional information
The relevant code currently appears to contradict its own comment:
go
// Concurrency is the maximum number of endpoints/suites that can be monitored concurrently
// Defaults to DefaultConcurrency. Set to 0 for unlimited concurrency.
Concurrency int yaml:"concurrency,omitempty"
But the validation logic contains:
} else if config.Concurrency <= 0 && !config.DisableMonitoringLock {
config.Concurrency = DefaultConcurrency
}
As a workaround, I configured an explicit positive value:
concurrency: 20
After this change, all seven affected endpoints reached the failure threshold and all 14 custom notifications and 14 email notifications were received successfully.
Describe the bug
In Gatus v5.36.0, concurrency: 0 is documented as enabling unlimited concurrency.
However, ValidateAndSetConcurrencyDefaults treats any value less than or equal to zero as unspecified and replaces it with DefaultConcurrency, which is 3.
The debug log confirms this behavior:
[config.ValidateAndSetConcurrencyDefaults] Setting default concurrency to 3
This can prevent endpoints from reaching their alert failure threshold when several slow checks run simultaneously.
What do you see?
I monitor 15 local ICMP endpoints with an interval of 1 second. Each endpoint has email and custom alerts configured with a failure threshold of 2.
With:
concurrency: 0
Gatus logs:
[config.ValidateAndSetConcurrencyDefaults] Setting default concurrency to 3
When a network switch is rebooted, several ICMP checks take 10 seconds to time out. Because only three checks run concurrently, each affected endpoint records at most one failure before the switch comes back online.
Therefore, the configured failure threshold of 2 is not reached and no email or custom notification is generated.
What do you expect to see?
concurrency: 0 should enable unlimited concurrency, as stated in the documentation.
Gatus should preserve the configured value of 0 instead of replacing it with the default value of 3.
Alternatively, if unlimited concurrency is no longer supported, the documentation and configuration comments should be updated accordingly.
List the steps that must be taken to reproduce this issue
Configure Gatus v5.36.0 with multiple endpoints and concurrency: 0:
concurrency: 0
alerting:
custom:
url: "https://example.invalid/notification"
default-alert:
failure-threshold: 2
success-threshold: 2
send-on-resolved: true
endpoints:
name: Endpoint 1
url: "icmp://192.0.2.1"
interval: 1s
conditions:
alerts:
name: Endpoint 2
url: "icmp://192.0.2.2"
interval: 1s
conditions:
alerts:
Start Gatus with GATUS_LOG_LEVEL=DEBUG.
Observe this message:
[config.ValidateAndSetConcurrencyDefaults] Setting default concurrency to 3
Replace the configuration with:
concurrency: 20
Restart Gatus.
Observe that the configured value is now respected:
[config.ValidateAndSetConcurrencyDefaults] Using configured concurrency of 20
With concurrency: 20, simultaneous endpoint failures correctly reach the alert threshold and notifications are generated.
Version
v5.36.0
Additional information
The relevant code currently appears to contradict its own comment:
go
// Concurrency is the maximum number of endpoints/suites that can be monitored concurrently
// Defaults to DefaultConcurrency. Set to 0 for unlimited concurrency.
Concurrency int yaml:"concurrency,omitempty"
But the validation logic contains:
} else if config.Concurrency <= 0 && !config.DisableMonitoringLock {
config.Concurrency = DefaultConcurrency
}
As a workaround, I configured an explicit positive value:
concurrency: 20
After this change, all seven affected endpoints reached the failure threshold and all 14 custom notifications and 14 email notifications were received successfully.