Implement healthcheck endpoint #43

New Issue

GiteaMirror · 2025-11-19T07:12:43-06:00

GiteaMirror commented

2025-11-19 07:12:43 -06:00

Originally created by @sebastiangaiser on GitHub (Jul 28, 2025).

Hey,

I experienced that newt was not able to connect. After a simple restart the connect was successful.
In this case it would be helpful if a HTTP based api would return that newt was not fully started. This then could be used for a health check, e.g. when running in Kubernetes by building a readiness probe.

Let me know what you think. Thanks

Originally created by @sebastiangaiser on GitHub (Jul 28, 2025). Hey, I experienced that newt was not able to connect. After a simple restart the connect was successful. In this case it would be helpful if a HTTP based api would return that newt was not fully started. This then could be used for a health check, e.g. when running in Kubernetes by building a [readiness probe](https://kubernetes.io/docs/concepts/configuration/liveness-readiness-startup-probes/#readiness-probe). Let me know what you think. Thanks

GiteaMirror closed this issue

2025-11-19 07:12:43 -06:00

GiteaMirror commented

2025-11-19 07:12:44 -06:00

@itsbhanusharma commented on GitHub (Jul 31, 2025):

Hey,

Adding to this, maybe my issue is totally unrelated but we experience newt is not able to re-establish connections in case the host (or Router) (or Internet in general) loses connection. We have backup internet so technically if newt is trying to reconnect it should be able to reconnect using the new route. However, it seems like newt is sticking to the one route it has established (aka primary) and if primary goes down, newt will not connect work correctly unless restarted. Maybe there is a way to implement some internal checks too which ensure that if newt is not able to reach the server, it either alerts or retries somehow.

in the latest version there is a Healthy health check which is working great for my use case

@itsbhanusharma commented on GitHub (Jul 31, 2025): Hey, ~~Adding to this, maybe my issue is totally unrelated but we experience newt is not able to re-establish connections in case the host (or Router) (or Internet in general) loses connection. We have backup internet so technically if newt is trying to reconnect it should be able to reconnect using the new route. However, it seems like newt is sticking to the one route it has established (aka primary) and if primary goes down, newt will not connect work correctly unless restarted. Maybe there is a way to implement some internal checks too which ensure that if newt is not able to reach the server, it either alerts or retries somehow.~~ in the latest version there is a Healthy health check which is working great for my use case

GiteaMirror commented

2025-11-19 07:12:44 -06:00

@macdaddybighorn commented on GitHub (Aug 20, 2025):

in the latest version there is a Healthy health check which is working great for my use case

I'm not seeing a health check in my docker instance running newt 1.4.1 (latest). I also experienced this issue a couple times when the pangolin docker stack updated (auto update via watchtower) and newt failed to connect when it was re-created. A simple restart allows it to connect and continue working fine. The error I saw in the logs was:

ERROR: 2025/08/19 08:42:53 Failed to resolve endpoint: DNS lookup failed: lookup mydomain.com on 127.0.0.11:53: server misbehaving
INFO: 2025/08/19 08:42:53 Received registration message
INFO: 2025/08/19 08:42:53 Connecting to endpoint: mydomain.com

It repeats continuously until restarted.

@macdaddybighorn commented on GitHub (Aug 20, 2025): > in the latest version there is a Healthy health check which is working great for my use case I'm not seeing a health check in my docker instance running newt 1.4.1 (latest). I also experienced this issue a couple times when the pangolin docker stack updated (auto update via watchtower) and newt failed to connect when it was re-created. A simple restart allows it to connect and continue working fine. The error I saw in the logs was: ``` ERROR: 2025/08/19 08:42:53 Failed to resolve endpoint: DNS lookup failed: lookup mydomain.com on 127.0.0.11:53: server misbehaving INFO: 2025/08/19 08:42:53 Received registration message INFO: 2025/08/19 08:42:53 Connecting to endpoint: mydomain.com ``` It repeats continuously until restarted.

GiteaMirror commented

2025-11-19 07:12:44 -06:00

@itsbhanusharma commented on GitHub (Aug 20, 2025):

I'm not seeing a health check in my docker instance running newt 1.4.1 (latest).

did you enable the healthcheck using environment variable?

I have added this to my compose.yaml

     environment:
      - HEALTH_FILE=/tmp/healthy

And then a healthcheck as follows:

    healthcheck:
      test: ["CMD", "test", "-f", "/tmp/healthy"]
      interval: 5s
      timeout: 2s
      retries: 2
      start_period: 10s

@itsbhanusharma commented on GitHub (Aug 20, 2025): > I'm not seeing a health check in my docker instance running newt 1.4.1 (latest). did you enable the healthcheck using environment variable? I have added this to my compose.yaml ``` environment: - HEALTH_FILE=/tmp/healthy ``` And then a healthcheck as follows: ``` healthcheck: test: ["CMD", "test", "-f", "/tmp/healthy"] interval: 5s timeout: 2s retries: 2 start_period: 10s ```

GiteaMirror commented

2025-11-19 07:12:44 -06:00

@sebastiangaiser commented on GitHub (Aug 20, 2025):

@itsbhanusharma thanks for pointing that out. I was more looking for e.g. a /healthz and/or /readyz http based endpoint.

@sebastiangaiser commented on GitHub (Aug 20, 2025): @itsbhanusharma thanks for pointing that out. I was more looking for e.g. a `/healthz` and/or `/readyz` http based endpoint.

GiteaMirror commented

2025-11-19 07:12:45 -06:00

@oschwartz10612 commented on GitHub (Aug 23, 2025):

I think what @itsbhanusharma explains is what we will stick with for
now. BUT if we add a http API like is budding in fosrl/olm then we could
definitely add it there! ;}

@oschwartz10612 commented on GitHub (Aug 23, 2025): I think what @itsbhanusharma explains is what we will stick with for now. BUT if we add a http API like is budding in fosrl/olm then we could definitely add it there! ;}

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/newt#43