[GH-ISSUE #908] Conditional integration selection based on tags #635

New issue

Closed

opened 2026-02-25 23:43:07 +03:00 by kerem · 3 comments

kerem commented

2026-02-25 23:43:07 +03:00

Owner

Originally created by @hialvaro on GitHub (Oct 17, 2023).
Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/908

As a user, I would like to have an integration (email, slack...) with conditional targets.

For example, if the healthcheck has the devops tag it should notify the devops@example.com mail, if it has the developers tag it should notify the developers@example.com mail. For this, an integration should have multiple targets that are conditionally selected based on a tag.

Thank you for this awesome project.

Originally created by @hialvaro on GitHub (Oct 17, 2023). Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/908 As a user, I would like to have an integration (email, slack...) with conditional targets. For example, if the healthcheck has the `devops` tag it should notify the `devops@example.com` mail, if it has the `developers` tag it should notify the `developers@example.com` mail. For this, an integration should have multiple targets that are conditionally selected based on a tag. Thank you for this awesome project.

kerem

2026-02-25 23:43:07 +03:00

closed this issue
added the
feature
label

kerem commented

2026-02-25 23:43:07 +03:00

Author

Owner

@cuu508 commented on GitHub (Oct 17, 2023):

This is an interesting idea but it conflicts with the already existing functionality:

Currently users define many-to-many mapping between checks and integrations. i.e., they explicitly select which integrations are are enabled for which checks. Conditionally enabling integrations based on matching tags would conflict with this: which mechanism takes precedence? How do we make sure the user knows and expects this?
Currently, when a new check is created, all existing integrations are auto-assigned to it. Again, conditionally enabling integrations based on matching tags would conflict with this. We would have to break backwards compatibility.

Can you describe the use case (the more detail the better, ideally with specific actor names, specific check names, specific integration types, specific scenarios) you are working with?

Perhaps the recently added "group" integration may be useful?

@cuu508 commented on GitHub (Oct 17, 2023): This is an interesting idea but it conflicts with the already existing functionality: * Currently users define many-to-many mapping between checks and integrations. i.e., they explicitly select which integrations are are enabled for which checks. Conditionally enabling integrations based on matching tags would conflict with this: which mechanism takes precedence? How do we make sure the user knows and expects this? * Currently, when a new check is created, all existing integrations are auto-assigned to it. Again, conditionally enabling integrations based on matching tags would conflict with this. We would have to break backwards compatibility. Can you describe the use case (the more detail the better, ideally with specific actor names, specific check names, specific integration types, specific scenarios) you are working with? Perhaps the recently added "group" integration may be useful?

kerem commented

2026-02-25 23:43:07 +03:00

Author

Owner

@hialvaro commented on GitHub (Oct 17, 2023):

Hi @cuu508 , thank you for your reply. I see this "conditional integration" just as the group integration (which could work for my use case, and I haven't seen before), a new kind of integration.

The user would create a new conditional integration, and inside that one it could decide based on some parameters (mainly tags) to which other integration it goes. For example:

When healthcheck has tag `devops` send to:
- [x] Slack devops
- [x] Mail devops

When healthcheck has tag `developers` send to:
- [x] Slack developers

Another way to implement this could be a conditional option inside each integration. For example, inside the slack integration there could be a conditional checkbox, when activated the user could set something like:

If `tag = devops` send to channel `devops`
If `tag = developers` send to channel `developers`

I don't think this would conflict on either of the two points, since the integrations are not enabled conditionally but it is a new kind of integration, which can be conditional to select what to do based on tags. Other conditionals could be status, name, etc.

@hialvaro commented on GitHub (Oct 17, 2023): Hi @cuu508 , thank you for your reply. I see this "conditional integration" just as the group integration (which could work for my use case, and I haven't seen before), a new kind of integration. The user would create a new conditional integration, and inside that one it could decide based on some parameters (mainly tags) to which other integration it goes. For example: ``` When healthcheck has tag `devops` send to: - [x] Slack devops - [x] Mail devops When healthcheck has tag `developers` send to: - [x] Slack developers ``` Another way to implement this could be a conditional option inside each integration. For example, inside the `slack` integration there could be a `conditional` checkbox, when activated the user could set something like: ``` If `tag = devops` send to channel `devops` If `tag = developers` send to channel `developers` ``` I don't think this would conflict on either of the two points, since the integrations are not enabled conditionally but it is a new kind of integration, which can be conditional to select what to do based on tags. Other conditionals could be `status`, `name`, etc.

kerem commented

2026-02-25 23:43:07 +03:00

Author

Owner

@cuu508 commented on GitHub (Nov 20, 2025):

Thanks for the suggestion. I am not planning to work on this. I'd like to keep Healthchecks lean and simple, and this feature is a little too niche for me.

@cuu508 commented on GitHub (Nov 20, 2025): Thanks for the suggestion. I am not planning to work on this. I'd like to keep Healthchecks lean and simple, and this feature is a little too niche for me.