[GH-ISSUE #271] Support Apprise to Simplify all of your Notification Requests

kerem commented

2026-02-25 23:41:34 +03:00

Owner

Originally created by @caronc on GitHub (Aug 6, 2019).
Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/271

I recently had an enhancement request opened for Apprise to support your service. But having visited your site and seeing you have already open requests for:

Gotify #270
Twilio #222
Zulip #202
Flock #159

It might make more sense to just add an APPRISE_URL variable inside your hc/settings.py file and kill all your birds with one stone (and more). It should be relatively trivial to do since Apprise is python based as well.

Thoughts?

Originally created by @caronc on GitHub (Aug 6, 2019). Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/271 I recently had an [enhancement request opened for Apprise](https://github.com/caronc/apprise/issues/139) to support your service. But having visited your site and seeing you have already open requests for: * Gotify #270 * Twilio #222 * Zulip #202 * Flock #159 It might make more sense to just add an `APPRISE_URL` variable inside your `hc/settings.py` file and kill all your birds with one stone (and more). It should be relatively trivial to do since [Apprise](https://github.com/caronc/apprise) is python based as well. Thoughts?

kerem closed this issue

2026-02-25 23:41:34 +03:00

kerem commented

2026-02-25 23:41:35 +03:00

Author

Owner

@cuu508 commented on GitHub (Aug 8, 2019):

Thanks for the suggestion and the PR – it looks simple (good!) and clean.

Apprise looks like a well-designed, versatile tool for sending notifications, but I have a few concerns about integrating it:

Credentials in Apprise URLs. I think what's likely to happen is people will put things like their root AWS keys in the URLs. Which increases the liability & risks for me. Obviously the existing integrations already contain credentials and secrets, but they usually have a tight scope, and fewer are needed. For example, users cannot and don't need to specify Twilio keys for sending SMS.
Security risks for the hosting platform. People are free to enter any Apprise URLs they like. At a quick glance through the supported notification services, they could send DBUS messages on the local server. Or post JSON payloads to localhost:anyport. I would need to make an extensive audit of all supported notification services (or white-list them one by one) to be comfortable running this.
Extra dependencies. Apprise brings in PyYAML, markdown and oauthlib. Not a big issue, but worth pointing out.
Duplication of functionality. Two ways to send a Slack notification, two ways to send a Telegram message etc. On one hand, it's more power to the user, on the other hand it's more decisions (which method to use?) and potential for confusion.
User friendliness. The Apprise notifications would be great for expert users, but could be problematic with non-technical users ("is it an external service or a library?", "It asks me to enter an URL with a token. Where do I get the token?").

One idea I have is – how about making this integration optional? A boolean APPRISE_ENABLED flag in settings.py or similar. This way, operators of self-hosted Healthchecks instances could make their own decision whether to use it or not.

@cuu508 commented on GitHub (Aug 8, 2019): Thanks for the suggestion and the PR – it looks simple (good!) and clean. Apprise looks like a well-designed, versatile tool for sending notifications, but I have a few concerns about integrating it: * **Credentials in Apprise URLs.** I think what's likely to happen is people will put things like their root AWS keys in the URLs. Which increases the liability & risks for me. Obviously the existing integrations already contain credentials and secrets, but they usually have a tight scope, and fewer are needed. For example, users cannot and don't need to specify Twilio keys for sending SMS. * **Security risks for the hosting platform.** People are free to enter any Apprise URLs they like. At a quick glance through the supported notification services, they could send DBUS messages on the local server. Or post JSON payloads to `localhost:anyport`. I would need to make an extensive audit of all supported notification services (or white-list them one by one) to be comfortable running this. * **Extra dependencies.** Apprise brings in PyYAML, markdown and oauthlib. Not a big issue, but worth pointing out. * **Duplication of functionality.** Two ways to send a Slack notification, two ways to send a Telegram message etc. On one hand, it's more power to the user, on the other hand it's more decisions (which method to use?) and potential for confusion. * **User friendliness.** The Apprise notifications would be great for expert users, but could be problematic with non-technical users ("is it an external service or a library?", "It asks me to enter an URL with a token. Where do I get the token?"). One idea I have is – how about making this integration optional? A boolean `APPRISE_ENABLED` flag in `settings.py` or similar. This way, operators of self-hosted Healthchecks instances could make their own decision whether to use it or not.

kerem commented

2026-02-25 23:41:35 +03:00

Author

Owner

@caronc commented on GitHub (Aug 8, 2019):

Your concerns are valid. If I can just comment on a few of them though:

As per some of your security points:
- Removing support for a plugin (as you referenced dbus://, json://, etc) at this time just involves removing it from the plugins/ directory (of Apprise); that directory is dynamically loaded. If the plugin isn't there, it simply isn't supported.
- The JSON response itself is very static. So if someone was naive (or toxic) enough to point the requests back to your server (using localhost), you wouldn't experience a breach of any kind. In addition to this, a DDOS using Apprise against your own hosting service (via localhost:port) would have to be very well coordinated through many, many, many accounts. Regardless, you do bring up a valid enhancement I should consider... Perhaps adding some security settings to Apprise for web-hosting services like yourself. One that would shut down local dbus calls automatically (without having to remove the plugin), and deny references to localhost, 127.0.0.1, socket.gethostname(), etc.
As per user friendliness: a Apprise().details() call can return all of the supported notification services (dynamically) and the tokens you need to build the URLs with. Thus you can actually make the user's experience much easier not having them have to enter a URL but just provide dynamic options. Apprise can construct a URL for database storage, and return the tokens for User presentation. But I realize this still doesn't address your concern about storing all of these tokens in the first place.

how about making this integration optional? A boolean APPRISE_ENABLED flag in settings.py or similar.

Not a problem at all, if you're still interested in keeping Apprise as an option, I can update the PR tonight (worst case on the weekend). 🙂

Thanks for your quick response by the way!

@caronc commented on GitHub (Aug 8, 2019): Your concerns are valid. If I can just comment on a few of them though: * **As per some of your security points**: * Removing support for a plugin (as you referenced _dbus://_, _json://_, etc) at this time just involves removing it from the `plugins/` directory (of Apprise); that directory is dynamically loaded. If the plugin isn't there, it simply isn't supported. * The [JSON response](https://github.com/caronc/apprise/wiki/Notify_Custom_JSON) itself is very static. So if someone was naive (or toxic) enough to point the requests back to your server (using localhost), you wouldn't experience a breach of any kind. In addition to this, a DDOS using Apprise against your own hosting service (via localhost:port) would have to be very well coordinated through many, many, many accounts. Regardless, you do bring up a valid enhancement I should consider... Perhaps adding some security settings to Apprise for web-hosting services like yourself. One that would shut down local dbus calls automatically (without having to remove the plugin), and deny references to _localhost_, _127.0.0.1_, _socket.gethostname()_, etc. * **As per user friendliness**: a [Apprise().details()](https://github.com/caronc/apprise/wiki/Development_Apprise_Details#schemas) call can return all of the supported notification services (dynamically) and the tokens you need to build the URLs with. Thus you can actually make the user's experience much easier not having them have to enter a URL but just provide dynamic options. Apprise can construct a URL for database storage, and return the tokens for User presentation. But I realize this still doesn't address your concern about storing all of these tokens in the first place. > how about making this integration optional? A boolean `APPRISE_ENABLED` flag in `settings.py` or similar. Not a problem at all, if you're still interested in keeping Apprise as an option, I can update the PR tonight (worst case on the weekend). :slightly_smiling_face: Thanks for your quick response by the way!

kerem commented

2026-02-25 23:41:35 +03:00

Author

Owner

@cuu508 commented on GitHub (Aug 8, 2019):

Yes, I'm open to having Apprise as an option–please do update the PR!

@cuu508 commented on GitHub (Aug 8, 2019): Yes, I'm open to having Apprise as an option–please do update the PR!

kerem commented

2026-02-25 23:41:35 +03:00

Author

Owner

@caronc commented on GitHub (Aug 9, 2019):

I pushed the rest of the changes last night; i'll let you review it. I also just noticed that this request will also handle the following other open tickets for you as well:

MS Teams: #135
IFTTT: #80

@caronc commented on GitHub (Aug 9, 2019): I pushed the rest of the changes last night; i'll let you review it. I also just noticed that this request will also handle the following other open tickets for you as well: * MS Teams: #135 * IFTTT: #80

kerem commented

2026-02-25 23:41:35 +03:00

Author

Owner

@immanuelfodor commented on GitHub (Aug 10, 2019):

I'm here for the Gotify support, but it would be awesome to have Apprise in this project for accessing further integrations.

@immanuelfodor commented on GitHub (Aug 10, 2019): I'm here for the Gotify support, but it would be awesome to have Apprise in this project for accessing further integrations.

kerem commented

2026-02-25 23:41:35 +03:00

Author

Owner

@cuu508 commented on GitHub (Aug 12, 2019):

@caronc thanks, looks good!

I made a quick attempt at a simplified vector icon for the "My Checks" screen:

Does that look OK to you? I think it would be too small to fit the letter "A" in there.

@cuu508 commented on GitHub (Aug 12, 2019): @caronc thanks, looks good! I made a quick attempt at a simplified vector icon for the "My Checks" screen: ![image](https://user-images.githubusercontent.com/661859/62859052-bf638500-bd04-11e9-9919-0ea9567f140e.png) Does that look OK to you? I think it would be too small to fit the letter "A" in there.

kerem commented

2026-02-25 23:41:35 +03:00

Author

Owner

@caronc commented on GitHub (Aug 12, 2019):

Looks great! 🙂

@caronc commented on GitHub (Aug 12, 2019): Looks great! 🙂

Rows
Columns

[GH-ISSUE #271] Support Apprise to Simplify all of your Notification Requests #204