Feature request: Define a start interval for the healthcheck #396

New Issue

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

saavagebueno commented

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

Originally created by @ncovercash on GitHub (May 3, 2024).

What's the feature?

Docker, in API 1.44+ (and engine/compose 24+?) introduced a new feature that defines an interval to conduct healthchecks during the startup period: docker create doc with --health-start-interval, release of compose. This allows rapid checks of health while a container starts up, then falls back to the regular interval once the container has started.

This is ideal for applications such as this image, where it may take a few seconds to start up, and then does not need to be poked often (hence the current interval of 1m). It would be nice if this image would define a start interval, ideally with a small (5s?) value, as the container would be able to become healthy much quicker and speed up deployments!

Extra information?

The version of docker provided in GitHub Actions may be a bit too old to build with this newer flag. You can add the following to your workflow to workaround this:

      - name: Print Docker version
        run: docker version

      - name: Install Latest Docker
        run: |
          curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
          sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu  $(lsb_release -cs)  stable"
          sudo apt-get update
          sudo apt-get install docker-ce

Originally created by @ncovercash on GitHub (May 3, 2024). 1. What's the feature? Docker, in API 1.44+ (and engine/compose 24+?) introduced a new feature that defines an interval to conduct healthchecks during the startup period: [docker create doc with --health-start-interval](https://docs.docker.com/reference/cli/docker/container/create/), [release of compose](https://github.com/docker/compose/releases/tag/v2.24.1). This allows rapid checks of health while a container starts up, then falls back to the regular interval once the container has started. This is ideal for applications such as this image, where it may take a few seconds to start up, and then does not need to be poked often (hence the current interval of 1m). It would be nice if this image would define a start interval, ideally with a small (5s?) value, as the container would be able to become healthy much quicker and speed up deployments! 2. Extra information? The version of docker provided in GitHub Actions may be a bit too old to build with this newer flag. You can add the following to your workflow to workaround this: ``` - name: Print Docker version run: docker version - name: Install Latest Docker run: | curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add - sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" sudo apt-get update sudo apt-get install docker-ce ```

saavagebueno added the Status: 🗯️ Waiting for feedback Category: Healthcheck 🩺 labels 2025-11-20 04:23:32 -05:00

saavagebueno commented

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

@qdm12 commented on GitHub (Aug 17, 2024):

Hi there! Thanks for the suggestion and the learning moment! On the other hand, ddns-updater checks the health comparing the resolved domain names IPs with the last stored IP address

8f456977be/internal/health/check.go (L26)

This works well, especially after the program has started and sent an initial update (usually takes below 1 second);

Now how could we use this new start healthcheck, any suggestions? We can't use the same mechanism since the dns records could be outdated at program start before an update.

@qdm12 commented on GitHub (Aug 17, 2024): Hi there! Thanks for the suggestion and the learning moment! On the other hand, ddns-updater checks the health comparing the resolved domain names IPs with the last stored IP address https://github.com/qdm12/ddns-updater/blob/8f456977bedfd96a0a18b2897606f86c0de40d38/internal/health/check.go#L26 This works well, especially after the program has started and sent an initial update (usually takes below 1 second); Now how could we use this new start healthcheck, any suggestions? We can't use the same mechanism since the dns records could be outdated at program start before an update.

saavagebueno commented

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

@swensorm commented on GitHub (Feb 28, 2025):

Hello, and thank you very much for your effort building this indispensable application!

Was having a bit of discussion about this over in TrueNAS Apps because of the number of DNS queries we're seeing on local DNS adblocking (adguard/pinhole). The health interval is being adjusted to match your image but I ponder the question; is the container really unhealthy if a DNS fails to update?

I'm honestly uncertain for either argument. That existential question of how fast you want DNS fixed against how much constant querying you want.

Rather than extending the health intervals, I wonder if it would be more logical to have a frequent healthcheck, but only re-verify the DNS values of each domain at the same frequency as the configured PERIOD env variable?

@swensorm commented on GitHub (Feb 28, 2025): Hello, and thank you very much for your effort building this indispensable application! Was having a bit of discussion about this over in [TrueNAS Apps](https://github.com/truenas/apps/issues/1250) because of the number of DNS queries we're seeing on local DNS adblocking (adguard/pinhole). The health interval is being adjusted to match your image but I ponder the question; is the container really unhealthy if a DNS fails to update? I'm honestly uncertain for either argument. That existential question of how fast you want DNS fixed against how much constant querying you want. Rather than extending the health intervals, I wonder if it would be more logical to have a frequent healthcheck, but only re-verify the DNS values of each domain at the same frequency as the configured `PERIOD` env variable?

saavagebueno referenced this issue

2025-11-20 04:25:42 -05:00

[PR #402] added Kubernetes examples & documentation #685

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/ddns-updater#396