Feature request: app-level errors shouldn't affect container health #374

New Issue

saavagebueno · 2025-11-20T04:23:19-05:00

saavagebueno commented

2025-11-20 04:23:19 -05:00

Originally created by @SlavikCA on GitHub (Feb 19, 2024).

The software should differentiate between container errors and app errors.

For example, if user try to access http://ddns-updater/invalid-url - that's application-level error, it should be logged, but should not result in the container health degradation.

I think the container healthcheck should be downgraded in cases, such as lack of network connectivity (can't response to DNS requests), storage issues (can't read /write) config files, etc.

But app-level errors (such as error response from Cloudflare API) should be logged, displayed in UI, but not affect container health.

Currently (v2.6.0), when ddns-updater receives error response for API request, the container state changes to unhealthy, which makes UI unaccessible on system, where routing is done via Traefik, because Traefik doesn't route to unhealthy containers.

Originally created by @SlavikCA on GitHub (Feb 19, 2024). The software should differentiate between container errors and app errors. For example, if user try to access http://ddns-updater/invalid-url - that's application-level error, it should be logged, but should not result in the container health degradation. I think the container healthcheck should be downgraded in cases, such as lack of network connectivity (can't response to DNS requests), storage issues (can't read /write) config files, etc. But app-level errors (such as error response from Cloudflare API) should be logged, displayed in UI, but not affect container health. Currently (v2.6.0), when `ddns-updater` receives error response for API request, the container state changes to `unhealthy`, which makes UI unaccessible on system, where routing is done via Traefik, because Traefik doesn't route to unhealthy containers.

saavagebueno added the Category: Healthcheck 🩺 label 2025-11-20 04:23:19 -05:00

saavagebueno commented

2025-11-20 04:23:19 -05:00

@agjell commented on GitHub (May 14, 2025):

+1 for this. Using Docker healthcheck in this way is unexpected for most users, and creates unintended consequences. At least for those of us using Traefik. Traefik works correctly and as expected; unhealthy containers should not be routed/exposed, because they could be vulnerable to attacks. Docker healthcheck should simply report if the container and its apps are functioning as intended. Since an IP mismatch on a domain is not causing issues with the container (but rather a part of the main feature set), the container should remain healthy through a record update. Domain health should be monitored through other means.

Keep up the good work! ddns-updater is a great app, It's exactly what I was looking for! I'll just disable healthcheck until it's fixed :)

@agjell commented on GitHub (May 14, 2025): +1 for this. Using Docker healthcheck in this way is unexpected for most users, and creates unintended consequences. At least for those of us using Traefik. Traefik works correctly and as expected; unhealthy containers should not be routed/exposed, because they could be vulnerable to attacks. Docker healthcheck should simply report if the container and its apps are functioning as intended. Since an IP mismatch on a domain is not causing issues with the container (but rather a part of the main feature set), the container should remain healthy through a record update. Domain health should be monitored through other means. Keep up the good work! ddns-updater is a great app, It's exactly what I was looking for! I'll just disable healthcheck until it's fixed :)

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/ddns-updater#374