starred/healthchecks

Fork 0

mirror of https://github.com/healthchecks/healthchecks.git synced 2026-04-25 23:15:49 +03:00

[GH-ISSUE #675] SITE_NAME ignored on Integrations (at least VictorOps / Splunk OnCall) #486

New issue

Closed

opened 2026-02-25 23:42:38 +03:00 by kerem · 4 comments

kerem commented

2026-02-25 23:42:38 +03:00

Owner

Originally created by @s256 on GitHub (Jul 18, 2022).
Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/675

We are trying to get our custom SITE_NAME as monitoring_tool in VictorOps / Splunk On-Call, but unfortunately always Mychecks appears as monitoring_tool.

I am running healthchecks as a systemd with this config:

[Unit]
Description=my Cron Monitoring using healthchecks.io
Requires=nginx.service
After=network.target

[Service]
Environment=LC_ALL=C.UTF-8
Environment=LANG=C.UTF-8
Environment=SECRET_KEY=foobar
Environment=ALLOWED_HOSTS=foo@bar.com
Environment=DEBUG=True
Environment=VICTOROPS_ENABLED=True
Environment=DEFAULT_FROM_EMAIL=foo@bar.com
Environment=SITE_NAME="My Cron Monitoring"
Environment=REGISTRATION_OPEN=False
Environment=EMAIL_HOST=localhost
Environment=EMAIL_PORT=25
Environment=EMAIL_USE_TLS=False
Environment=EMAIL_USE_VERIFICATION=False
Environment=PING_EMAIL_DOMAIN=foo.bar
Environment=PING_ENDPOINT=https://foo.bar/ping/
WorkingDirectory=/opt/healthchecks/healthchecks
RuntimeDirectory=hc
ExecStart=/opt/healthchecks/.venv/bin/uwsgi /opt/healthchecks/uwsgi.ini
User=healthchecks
Restart=always
Type=notify
KillSignal=SIGQUIT
StandardError=syslog
NotifyAccess=all

[Install]
WantedBy=multi-user.target

and alerts with

[Unit]
Description=sendalerts
After=network-online.target
Wants=network-online.target

[Service]
Slice=machine.slice
Restart=always
RestartSec=20
StartLimitInterval=10
StartLimitBurst=5

User=healthchecks
Group=healthchecks

ExecStart=/opt/healthchecks/.venv/bin/python -u /opt/healthchecks/healthchecks/manage.py sendalerts --no-threads

PrivateDevices=true
ProtectHome=true
ProtectSystem=full

[Install]
WantedBy=multi-user.target

While the Web UI reflects the SITE_NAME - VictorOps does not.

I tried replacing the settings.SITE_NAME in https://github.com/healthchecks/healthchecks/blob/master/hc/settings.py#L158= with some hardcoded value, but nothing changes.
Also tried to replace it in the transports.py https://github.com/healthchecks/healthchecks/blob/master/hc/api/transports.py#L547 without success.

        payload = {
            "entity_id": str(check.code),
            "message_type": mtype,
            "entity_display_name": check.name_then_code(),
            "state_message": description,
            "monitoring_tool": "My Cron Monitor",
        }

I also tried running it without uwsgi in debug mode with manage.py runserver but still the same behaviour.
Additionally I removed all *.pyc files in the directory to make sure that's not a caching problem.

Expected Behaviour:
Replace all appearances of SITE_NAME with value from Environment variable.

Actual Behaviour:
SITE_NAME is only set in webUI but not in integrations.

Originally created by @s256 on GitHub (Jul 18, 2022). Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/675 We are trying to get our custom `SITE_NAME` as `monitoring_tool` in VictorOps / Splunk On-Call, but unfortunately always `Mychecks` appears as `monitoring_tool`. I am running `healthchecks` as a systemd with this config: ``` [Unit] Description=my Cron Monitoring using healthchecks.io Requires=nginx.service After=network.target [Service] Environment=LC_ALL=C.UTF-8 Environment=LANG=C.UTF-8 Environment=SECRET_KEY=foobar Environment=ALLOWED_HOSTS=foo@bar.com Environment=DEBUG=True Environment=VICTOROPS_ENABLED=True Environment=DEFAULT_FROM_EMAIL=foo@bar.com Environment=SITE_NAME="My Cron Monitoring" Environment=REGISTRATION_OPEN=False Environment=EMAIL_HOST=localhost Environment=EMAIL_PORT=25 Environment=EMAIL_USE_TLS=False Environment=EMAIL_USE_VERIFICATION=False Environment=PING_EMAIL_DOMAIN=foo.bar Environment=PING_ENDPOINT=https://foo.bar/ping/ WorkingDirectory=/opt/healthchecks/healthchecks RuntimeDirectory=hc ExecStart=/opt/healthchecks/.venv/bin/uwsgi /opt/healthchecks/uwsgi.ini User=healthchecks Restart=always Type=notify KillSignal=SIGQUIT StandardError=syslog NotifyAccess=all [Install] WantedBy=multi-user.target ``` and alerts with ``` [Unit] Description=sendalerts After=network-online.target Wants=network-online.target [Service] Slice=machine.slice Restart=always RestartSec=20 StartLimitInterval=10 StartLimitBurst=5 User=healthchecks Group=healthchecks ExecStart=/opt/healthchecks/.venv/bin/python -u /opt/healthchecks/healthchecks/manage.py sendalerts --no-threads PrivateDevices=true ProtectHome=true ProtectSystem=full [Install] WantedBy=multi-user.target ``` While the Web UI reflects the `SITE_NAME` - VictorOps does not. ![hc](https://user-images.githubusercontent.com/1517486/179549272-7ca288d2-5d51-4329-b64e-5c6999d9308a.jpg) ![hc_2](https://user-images.githubusercontent.com/1517486/179549571-5f85f593-bae6-4572-8a46-ebb75e47cdc7.jpg) I tried replacing the `settings.SITE_NAME` in https://github.com/healthchecks/healthchecks/blob/master/hc/settings.py#L158= with some hardcoded value, but nothing changes. Also tried to replace it in the `transports.py` https://github.com/healthchecks/healthchecks/blob/master/hc/api/transports.py#L547 without success. ``` payload = { "entity_id": str(check.code), "message_type": mtype, "entity_display_name": check.name_then_code(), "state_message": description, "monitoring_tool": "My Cron Monitor", } ``` I also tried running it without `uwsgi` in debug mode with `manage.py runserver` but still the same behaviour. Additionally I removed all `*.pyc` files in the directory to make sure that's not a caching problem. **Expected Behaviour:** Replace all appearances of `SITE_NAME` with value from Environment variable. **Actual Behaviour:** `SITE_NAME` is only set in webUI but not in integrations.

kerem closed this issue

2026-02-25 23:42:38 +03:00

kerem commented

2026-02-25 23:42:38 +03:00

Author

Owner

@cuu508 commented on GitHub (Jul 19, 2022):

You don't have Environment=SITE_NAME="My Cron Monitoring" in the sendalerts systemd unit, so it uses the default value, "Mychecks".

@cuu508 commented on GitHub (Jul 19, 2022): You don't have `Environment=SITE_NAME="My Cron Monitoring"` in the sendalerts systemd unit, so it uses the default value, "Mychecks".

kerem commented

2026-02-25 23:42:38 +03:00

Author

Owner

@s256 commented on GitHub (Jul 19, 2022):

Thank you, that fixed it... But why didn't my changes in https://github.com/healthchecks/healthchecks/blob/master/hc/api/transports.py#L547 lead to the same result?

payload = {
            "entity_id": str(check.code),
            "message_type": mtype,
            "entity_display_name": check.name_then_code(),
            "state_message": description,
            "monitoring_tool": "My Cron Monitor",
        }

Should have led to the same result, right?

@s256 commented on GitHub (Jul 19, 2022): Thank you, that fixed it... But why didn't my changes in https://github.com/healthchecks/healthchecks/blob/master/hc/api/transports.py#L547 lead to the same result? ``` payload = { "entity_id": str(check.code), "message_type": mtype, "entity_display_name": check.name_then_code(), "state_message": description, "monitoring_tool": "My Cron Monitor", } ``` Should have led to the same result, right?

kerem commented

2026-02-25 23:42:38 +03:00

Author

Owner

@cuu508 commented on GitHub (Jul 19, 2022):

Yes, it should have the same result. Two guesses:

perhaps something simple as multiple code checkouts, and you editing files in one location, but running the service from another location? I've run into this a few times myself :-)
after you made edits to transports.py, did you restart the sendalerts service?

@cuu508 commented on GitHub (Jul 19, 2022): Yes, it should have the same result. Two guesses: * perhaps something simple as multiple code checkouts, and you editing files in one location, but running the service from another location? I've run into this a few times myself :-) * after you made edits to transports.py, did you restart the `sendalerts` service?

kerem commented

2026-02-25 23:42:38 +03:00

Author

Owner

@s256 commented on GitHub (Jul 19, 2022):

probably number 2) not restarting the sendalerts but the uwsgi service...
Thank you! I'll close the issue. :)

@s256 commented on GitHub (Jul 19, 2022): probably number 2) not restarting the `sendalerts` but the `uwsgi` service... Thank you! I'll close the issue. :)