How to configure Notifications for a Homelab setup?

[sreeramachandramurthy]

I am trying to configure my gotify service in healthlog to send notifications as a webhook.

Current Setup

• I've setup healthlog and gotify in the same server as separate docker services using docker compose
• Both services have separate vlan IP addresses but are under same network
• Both services have reverse proxy enabled and SSL/TLS certificates provided by Nginx Proxy Manager

Error Log

When I setup my healthlog to publish notifications to use my existing gotify service and then clicking on Test connection, I get the Test failed error message. On further debugging, I noticed the following lines in the log

{
  "timestamp": "2026-09-10T13:11:41.046Z",
  "request_id": "717028b8-7c01-4a49-bb1a-766f341e7239",
  "trace_id": "41ece8ed-cd39-4daf-b239-c48d59df2ae6",
  "kind": "http",
  "service": "healthlog",
  "environment": "production",
  "deploy": {
    "node_version": "v22.23.1",
    "hostname": "xxxxxx"
  },
  "level": "error",
  "http": {
    "method": "POST",
    "path": "/api/settings/webhook/test",
    "route": "/api/settings/webhook/test",
    "status": 500,
    "user_agent": "Mozilla/5.0 (X11; Linux x86_64; rv:155.0) Gecko/20100101 Firefox/155.0",
    "ip": "10.xx.xx.xx"
  },
  "auth": {
    "user_id": "xxxxxx",
    "user_role": "ADMIN",
    "auth_method": "session"
  },
  "external_calls": [
    {
      "service": "webhook",
      "method": "sendNotification",
      "duration_ms": 99,
      "error": "safeFetch refused a private resolved destination"
    }
  ],
  "duration_ms": 159,
  "runtime": {
    "loop_max_ms": 1.7,
    "loop_last_ms": 0.5
  }
}

Initially I thought this was a bug but after reviewing the Privacy Architecture documentation and few existing issues #218 , #217 - it looks like this is intentional and a safety feature. Sending outbound notifications are only allowed to valid public IPs.

Since my setup is built entirely on homelab environment, my gotify URL resolves to a private IP. Is there a configuration setting or a workaround to send notifications in such valid scenarios?

[MBombeck]

You read it right: this is intentional, not a bug. Every outbound request
to a host you type in (webhook, ntfy) goes through an egress guard that
refuses a destination resolving to a private, loopback, link-local or
CGNAT address, and it checks the resolved address at connect time, so a
public name pointing at a LAN IP is exactly what it stops. That is the
DNS-rebinding defence from #217, and the test button uses the same path as
real delivery, so nothing would have reached Gotify either.

There is currently no switch for the notification channels. Two other
surfaces already have an operator-side allowlist (ALLOW_LOCAL_AI_PRIVATE_HOSTS
for local AI, NIGHTSCOUT_PRIVATE_ORIGINS for Nightscout); the senders do
not read either, and the test reporting a bare "failed" instead of the
reason is a gap too.

The plan is a third variable of the Nightscout shape, NOTIFICATION_PRIVATE_ORIGINS,
holding exact origins such as https://gotify.example.com. Listed origins
are dialled through the pinned resolver with redirects forbidden; loopback
and metadata ranges stay refused; nothing not listed widens. It is a small
change and will ship in a patch release; the notes will name this thread.

Until then the only thing that works with a private target is a name that
resolves to your public address with hairpin NAT on the router.

[sreeramachandramurthy]

@MBombeck - Thank you for understanding and planning to implement this feature. Much appreciated!

[MBombeck]

v1.38.17 is out with this: https://github.com/MBombeck/HealthLog/releases/tag/v1.38.17

Set NOTIFICATION_PRIVATE_ORIGINS in the server environment to the exact origin of your Gotify, for example https://gotify.example.com (scheme, host and port must match the URL you save; no path, no wildcard, no CIDR), pull the new image, and the test button will reach it. A private target that is not listed now answers with a message naming the variable instead of a bare failure, so the log detour you took is no longer needed. The environment-variables reference and the notifications guide on the docs site describe the grammar and what stays refused even when listed.

If it still refuses on your setup, the exact wording of the refusal and the value you set (with the host masked if you prefer) is all I need.

[MBombeck]

@sreeramachandramurthy thanks, that screenshot showed the problem right away, and it was mine.

Gotify says priority arrived as a string, which is the generic format, and your Gotify log shows the request went to /message?token=…. Your card shows the URL without a token and the format set to Gotify. So the test sent an older saved configuration, not what was on screen. Test always uses what is saved, and the card kept showing "Saved" after you changed a field, which made that impossible to notice.

v1.38.22 fixes that: the note goes away as soon as you change something, and Test waits until you save. https://github.com/MBombeck/HealthLog/releases/tag/v1.38.22

With the form as in your screenshot, press Save and then Test. It should go through. And good to hear Loki is working.

[sreeramachandramurthy]

Hi @MBombeck , after upgrading to latest version, v1.38.22, I was able to successfully configure and send the test message from healthlog to my gotify instance. I received the test message to my android mobile.

[sreeramachandramurthy]

@MBombeck - Apologies for restarting this closed thread again but I am still facing issues with notifications. I noticed that I haven't got any notifications from healthlog after configuring gotify webhook on 14th September. I started investigating today and noticed that the webhook has been auto-disabled in the UI.

Noticed webhook as Auto-disabled

I re-enabled the gotify webhook again which is successfully saved

I clicked on Test connection and got a Test message in my Android Gotify app

I clicked on Send test in Delivery Status and nothing happened. No logs as well.

I did not see any logs while clicking on Send test button - not even INFO logs. Since it's been 9 days I do not have logs for 14th September. I will try to capture logs from Grafana today after the webhook goes to auto-disabled state again.

[sreeramachandramurthy]

@MBombeck : this is working now. I've upgraded to v1.39.0 and I am able to receive notifications in Gotify now. Not sure if something was fixed in v1.39.0 or doing a docker compose up -d --force-recreate while upgrading done the trick.

[MBombeck]

@sreeramachandramurthy good to hear it is delivering again. Nothing in v1.39.0 changed the webhook sender, so the upgrade itself is unlikely to be what fixed it.

A channel switches itself off in two cases: the receiving side refuses it outright (for Gotify typically a 401 for a wrong or rotated app token, or a 404 for a wrong URL), or several deliveries in a row fail, for example while Gotify or the proxy in front of it is down. The "Delivery status" card in the notification settings shows the reason and the last failure for an auto-disabled channel, and "Re-enable" resets it. One more possibility in your setup: NOTIFICATION_PRIVATE_ORIGINS is read when the container starts, and docker compose restart does not pick up a changed environment, while docker compose up -d --force-recreate does. If the variable was missing from the running container for a while, every delivery would have been refused until the recreate.

If it switches itself off again, the reason and last failure from that card are the things to send me.