[GH-ISSUE #667] ENV variables for setting up webhooks #478

Closed
opened 2026-02-25 23:42:36 +03:00 by kerem · 9 comments
Owner

Originally created by @alexanderadam on GitHub (Jun 12, 2022).
Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/667

It seems that there are some default ENV variables for Slack (i.e. SLACK_CLIENT_ID, SLACK_CLIENT_SECRET and SLACK_ENABLED) but for Mattermost there's only MATTERMOST_ENABLED.

Is there any possibility to preconfigure healthchecks.io for selfhosted Mattermost instances via env variables as well?

Originally created by @alexanderadam on GitHub (Jun 12, 2022). Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/667 It seems that there are some [default ENV variables for Slack (i.e. `SLACK_CLIENT_ID`, `SLACK_CLIENT_SECRET` and `SLACK_ENABLED`)](https://github.com/healthchecks/healthchecks#slack) but for Mattermost there's only [`MATTERMOST_ENABLED`](https://healthchecks.io/docs/self_hosted_configuration/#MATTERMOST_ENABLED). Is there any possibility to preconfigure healthchecks.io for selfhosted Mattermost instances via env variables as well?
kerem closed this issue 2026-02-25 23:42:36 +03:00
Author
Owner

@cuu508 commented on GitHub (Jun 12, 2022):

What specifically do you want to preconfigure?

<!-- gh-comment-id:1153161590 --> @cuu508 commented on GitHub (Jun 12, 2022): What specifically do you want to preconfigure?
Author
Owner

@alexanderadam commented on GitHub (Jun 12, 2022):

Thank you for your fast response (and for healthchecks of course)!
I would love to preconfigure Mattermost webhooks.

<!-- gh-comment-id:1153262428 --> @alexanderadam commented on GitHub (Jun 12, 2022): Thank you for your fast response (_and for healthchecks of course_)! I would love to preconfigure Mattermost webhooks.
Author
Owner

@cuu508 commented on GitHub (Jun 13, 2022):

Instead of adding a Mattermost integration interactively in the web UI, you want to define it via environment variables, and have it available by default in every project, correct?

Note that SLACK_CLIENT_ID and SLACK_CLIENT_SECRET do something else: they are OAuth2 credentials that Healthchecks can optionally use when adding Slack integrations interactively, through the web UI. If they are not set, then Healthchecks falls back to using Slack's incoming webhooks, and works very similarly to the Mattermost integration.

<!-- gh-comment-id:1153528903 --> @cuu508 commented on GitHub (Jun 13, 2022): Instead of adding a Mattermost integration interactively in the web UI, you want to define it via environment variables, and have it available by default in every project, correct? Note that `SLACK_CLIENT_ID` and `SLACK_CLIENT_SECRET` do something else: they are OAuth2 credentials that Healthchecks can optionally use when adding Slack integrations interactively, through the web UI. If they are not set, then Healthchecks falls back to using Slack's incoming webhooks, and works very similarly to the Mattermost integration.
Author
Owner

@alexanderadam commented on GitHub (Jun 13, 2022):

Instead of adding a Mattermost integration interactively in the web UI, you want to define it via environment variables, and have it available by default in every project, correct?

Exactly.

Note that SLACK_CLIENT_ID and SLACK_CLIENT_SECRET do something else

Ah okay. I wasn't aware of that. 🙈
So in that case this would be generic request and I should rename it to "ENV variables to preconfigure webhooks" or so, right?

<!-- gh-comment-id:1153557788 --> @alexanderadam commented on GitHub (Jun 13, 2022): > Instead of adding a Mattermost integration interactively in the web UI, you want to define it via environment variables, and have it available by default in every project, correct? Exactly. > Note that `SLACK_CLIENT_ID` and `SLACK_CLIENT_SECRET` do something else Ah okay. I wasn't aware of that. 🙈 So in that case this would be generic request and I should rename it to "_ENV variables to preconfigure webhooks_" or so, right?
Author
Owner

@cuu508 commented on GitHub (Jun 13, 2022):

So in that case this would be generic request and I should rename it to "ENV variables to preconfigure webhooks" or so, right?

Yes. Also, can you describe your use case a little more? Adding a Mattermost integration in the web UI does not take much time and needs to be done only once per project. Are you setting up hundreds of Healthchecks instances, or hundreds of projects in an instance?

<!-- gh-comment-id:1153561099 --> @cuu508 commented on GitHub (Jun 13, 2022): > So in that case this would be generic request and I should rename it to "ENV variables to preconfigure webhooks" or so, right? Yes. Also, can you describe your use case a little more? Adding a Mattermost integration in the web UI does not take much time and needs to be done only once per project. Are you setting up hundreds of Healthchecks instances, or hundreds of projects in an instance?
Author
Owner

@alexanderadam commented on GitHub (Jun 13, 2022):

Are you setting up hundreds of Healthchecks instances, or hundreds of projects in an instance?

No, I just like reproducibility and use Ansible for setting up everything easily.

<!-- gh-comment-id:1153598159 --> @alexanderadam commented on GitHub (Jun 13, 2022): > Are you setting up hundreds of Healthchecks instances, or hundreds of projects in an instance? No, I just like reproducibility and use Ansible for setting up everything easily.
Author
Owner

@cuu508 commented on GitHub (Jun 13, 2022):

But would you be starting with a fresh database every time? Integration configurations live in the database, same as user accounts, checks, logged pings etc. If you are moving your Healthchecks instance to new hardware, you would typically be restoring an existing database backup.

<!-- gh-comment-id:1153732668 --> @cuu508 commented on GitHub (Jun 13, 2022): But would you be starting with a fresh database every time? Integration configurations live in the database, same as user accounts, checks, logged pings etc. If you are moving your Healthchecks instance to new hardware, you would typically be restoring an existing database backup.
Author
Owner

@alexanderadam commented on GitHub (Jun 13, 2022):

That's true. I would. It is mainly for having a quick setup of a new system with barely any manual configuration involved.

Creating a webhook possibility on the Mattermost side is trivial to automate.

For container images often most of the configuration can be done via ENV variables. So for many applications this is usually also true for authentication via OpenID or activating Prometheus endpoints.

This way, users can simply search for their desired apps on Ansible Galaxy or GitHub/GitLab and preconfigure their apps easily by filling a few variables.

But sure, setting up each thing manually by logging in + updating settings is possible.
And it's no big issue if you're only running one app or just a few. It might only become time-consuming if you have more applications, maybe even interacting with each other.

Of course I'm also fine if you decide that that it's not worth it for healthchecks.
It would just be an improvement for user experience, mainly for people who are using infrastructure as code tooling to get easy setups.
And it's even documented in code, so you won't forget what you had to configure how.

<!-- gh-comment-id:1153766279 --> @alexanderadam commented on GitHub (Jun 13, 2022): That's true. I would. It is mainly for having a quick setup of a new system with barely any manual configuration involved. [Creating a webhook possibility on the Mattermost side](https://docs.mattermost.com/manage/mmctl-command-line-tool.html#mmctl-webhook) is trivial to automate. For container images often most of the configuration can be done via ENV variables. So for many applications this is usually also true for [authentication via OpenID](https://github.com/healthchecks/healthchecks/issues/185) or [activating Prometheus endpoints](https://github.com/healthchecks/healthchecks/issues/300#issuecomment-588860211). This way, users can simply search for their desired apps on Ansible Galaxy or [GitHub](https://github.com/search?l=&q=image+%22linuxserver%2Fhealthchecks%22+language%3AYAML&type=code)/GitLab and preconfigure their apps easily by filling a few variables. But sure, setting up each thing manually by logging in + updating settings is possible. And it's no big issue if you're only running one app or just a few. It might only become time-consuming if you have more applications, maybe even interacting with each other. Of course I'm also fine if you decide that that it's not worth it for healthchecks. It would just be an improvement for user experience, mainly for people who are using infrastructure as code tooling to get easy setups. And it's even documented in code, so you won't forget what you had to configure how.
Author
Owner

@cuu508 commented on GitHub (Jun 13, 2022):

This project uses environment variables for system-wide configuration: credentials for sending email, credentials for connecting to the database, credentials for accessing object storage, and so on.

Integrations, same as user accounts and checks, are "data" that lives in the database. To automate creation of integrations, I would look into writing a new management command (similar to Mattermost's mmctl). And yes, I'm not yet convinced the extra complexity, maintenance and associated documentation would be worth it. For Mattermost, you could be potentially integrating it with many external systems that want to post notifications, and creating an incoming webhook for each. So mmctl is handy to have. But for Healthchecks, you would be setting up the integration only once per project. IMO it would be easier to create it in the web UI, rather than figure out what parameters to pass to the management command.

<!-- gh-comment-id:1153842862 --> @cuu508 commented on GitHub (Jun 13, 2022): This project uses environment variables for system-wide configuration: credentials for sending email, credentials for connecting to the database, credentials for accessing object storage, and so on. Integrations, same as user accounts and checks, are "data" that lives in the database. To automate creation of integrations, I would look into writing a new management command (similar to Mattermost's `mmctl`). And yes, I'm not yet convinced the extra complexity, maintenance and associated documentation would be worth it. For Mattermost, you could be potentially integrating it with many external systems that want to post notifications, and creating an incoming webhook for each. So `mmctl` is handy to have. But for Healthchecks, you would be setting up the integration only once per project. IMO it would be easier to create it in the web UI, rather than figure out what parameters to pass to the management command.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/healthchecks#478
No description provided.