I had a healthcheck for a publicly accessible resource. It pointed to an url:port that was no longer accessible, I think at some point the check was correct but then I must have changed some deployments. The thing is that the service was not accessible because that healthcheck was wrong (newt was complaining about it, that's how I found that it was the issue).
Disabling the healthcheck made the resource available again.
My point is that a healthcheck, which is basically meant to get notified about potential issues, should not block access to the actual resources if they're available.
Environment
OS Type & Version: (e.g., Ubuntu 22.04)
Pangolin Version: 1.16
Gerbil Version:
Traefik Version:
Newt Version: 1.9
Olm Version: (if applicable)
To Reproduce
Setup a publicly accessible resource with a wrong healthcheck test
Expected Behavior
The service is still accessible from the outside
Originally created by @svillar on GitHub (Apr 4, 2026).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/2787
### Describe the Bug
I had a healthcheck for a publicly accessible resource. It pointed to an url:port that was no longer accessible, I *think* at some point the check was correct but then I must have changed some deployments. The thing is that the service was not accessible because that healthcheck was wrong (newt was complaining about it, that's how I found that it was the issue).
Disabling the healthcheck made the resource available again.
My point is that a healthcheck, which is basically meant to get notified about potential issues, should not block access to the actual resources if they're available.
### Environment
- OS Type & Version: (e.g., Ubuntu 22.04)
- Pangolin Version: 1.16
- Gerbil Version:
- Traefik Version:
- Newt Version: 1.9
- Olm Version: (if applicable)
### To Reproduce
Setup a publicly accessible resource with a wrong healthcheck test
### Expected Behavior
The service is still accessible from the outside
@oschwartz10612 commented on GitHub (Apr 4, 2026):
Hey, thanks for the thought! This is actually expected behavior. When a
health check fails the target gets taken out of rotation so other
targets if available can serve the resource or so the user sees a "no
server available" which is the expected error message in this case.
<!-- gh-comment-id:4187193757 -->
@oschwartz10612 commented on GitHub (Apr 4, 2026):
Hey, thanks for the thought! This is actually expected behavior. When a
health check fails the target gets taken out of rotation so other
targets if available can serve the resource or so the user sees a "no
server available" which is the expected error message in this case.
This is normal LB behavior. AWS for example:
https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-health-checks.html#target-health-states:~:text=Each%20load%20balancer%20node%20routes%20requests%20only%20to%20the%20healthy%20targets%20in%20the%20enabled%20Availability%20Zones%20for%20the%20load%20balancer.
Ok, a misinterpretation from my side of what the healthcheck means. Your explanation makes a lot of sense. Thanks for the great work folks!
<!-- gh-comment-id:4197046234 -->
@svillar commented on GitHub (Apr 7, 2026):
Ok, a misinterpretation from my side of what the healthcheck means. Your explanation makes a lot of sense. Thanks for the great work folks!
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @svillar on GitHub (Apr 4, 2026).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/2787
Describe the Bug
I had a healthcheck for a publicly accessible resource. It pointed to an url:port that was no longer accessible, I think at some point the check was correct but then I must have changed some deployments. The thing is that the service was not accessible because that healthcheck was wrong (newt was complaining about it, that's how I found that it was the issue).
Disabling the healthcheck made the resource available again.
My point is that a healthcheck, which is basically meant to get notified about potential issues, should not block access to the actual resources if they're available.
Environment
To Reproduce
Setup a publicly accessible resource with a wrong healthcheck test
Expected Behavior
The service is still accessible from the outside
@oschwartz10612 commented on GitHub (Apr 4, 2026):
Hey, thanks for the thought! This is actually expected behavior. When a
health check fails the target gets taken out of rotation so other
targets if available can serve the resource or so the user sees a "no
server available" which is the expected error message in this case.
This is normal LB behavior. AWS for example:
https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-health-checks.html#target-health-states:~:text=Each%20load%20balancer%20node%20routes%20requests%20only%20to%20the%20healthy%20targets%20in%20the%20enabled%20Availability%20Zones%20for%20the%20load%20balancer.
@svillar commented on GitHub (Apr 7, 2026):
Ok, a misinterpretation from my side of what the healthcheck means. Your explanation makes a lot of sense. Thanks for the great work folks!