[Feature]: accepted_statuscodes

[ThiBot77]

Feature Description

Currently, HTTPS probes consider only a fixed set of HTTP status codes as successful responses. This can be limiting for certain use cases where other status codes should be treated as valid (for example, 401, 403, 429, or specific 3xx responses).

Feature request:

Add the ability to configure a list or range of accepted HTTP status codes for HTTPS probes.

Motivation

This feature would be useful because HTTP status codes alone do not always reflect the real health of a service.

Many production systems intentionally return status codes other than 200 OK while still functioning correctly. When HTTPS probes treat only a fixed set of status codes as successful, this can lead to false alerts, misleading monitoring results, and unnecessary operational noise.

Here are some concrete reasons why configurable accepted status codes are valuable:

Authenticated endpoints
Some services require authentication and will return 401 Unauthorized or 403 Forbidden when accessed without credentials. Even so, the service itself may be fully operational. Being able to mark these status codes as accepted allows monitoring the availability of the service without exposing credentials.

Redirect-based architectures
Many applications rely on redirects (301, 302, 307, 308) for traffic routing, HTTPS enforcement, or load balancing. Treating these responses as failures does not accurately represent the service’s health.

APIs with valid non-200 responses
APIs may return 204 No Content, 202 Accepted, or 429 Too Many Requests under normal and expected conditions. These responses can indicate that the service is reachable and functioning as designed.

Reduced false positives
Strict status code validation can cause probes to fail even when the service is up, leading to alert fatigue. Allowing users to define accepted status codes improves signal quality and trust in monitoring alerts.

Alternatives Considered

No response

Additional Context

No response

Checklist

• I have searched existing issues to make sure this feature hasn’t been requested yet.
• I have described the feature clearly and provided supporting details.