In a discussion about email/webhook notifications for critical security updates in Discourse, markersocial suggests admins should receive alerts via email or webhook when critical updates are available—mirroring the dashboard warning. JammyDodger points out that existing settings (‘version checks’ and ‘new version emails’) may already handle this, as critical updates typically trigger version bumps. markersocial acknowledges this but notes the alert email must be publicly listed on the /about page via ‘contact_email’, which they left empty in favor of ‘contact_url’. They argue administrative alerts should go to a separate, private email (e.g., server admin) rather than the public support email. JammyDodger agrees and references an open UX topic proposing more configurable email destinations for such alerts: Change sending new version email to developer email or configurable group.
I think it would be nice if admins could receive an email when there is a new critical update available for a Discourse instance (according to the branch being used). Even better would be if a webhook could be triggered.
Essentially for the same conditions in which the ’ A critical update is available. Please upgrade!’ message is shown on the admin dashboard.
Is this not provided by the version checks and new version emails settings?
I think a critical update would get a version bump, which should trigger both of those?
Thanks @JammyDodger!
I somehow missed that when searching.
Though it appears that the email used for this setting must be listed publicly on the /about page.
I had left ‘contact_email’ empty (opting for using contact_url), which explains why I have not been receiving these emails.
I do think that the email used for administrative critical alerts shouldn’t be the same as the email listed publicly for support/general contact emails though.
One email would make more sense to go to a support ticketing system, while the other should go to the server admin.
Now you mention it, that does sound familiar. I think there’s an open Contribute > UX topic here suggesting making those emails more configurable: