Enable email subscription to status page updates (self-registration) #4717

Closed
opened 2026-02-28 04:12:52 -05:00 by deekerman · 2 comments
Owner

Originally created by @catsdev on GitHub (Feb 15, 2026).

I found several existing issues and discussions around “self‑registration”, however they are focused on allowing users to register as Uptime Kuma system users or admins.

This request is different in scope:

  • It is not about granting access to the dashboard or monitors
  • It is only about allowing external consumers of a status page to subscribe to notifications
  • Subscribers would have read‑only access and receive email notifications only

I did not find an existing issue that specifically addresses self‑registration for status page notification consumers.

🔖 Feature description

Uptime Kuma provides excellent monitoring and public status pages, but currently there is no way for end users to subscribe to updates directly from a status page.

For enterprise and large-scale usage, it would be very valuable to allow users to self-register for notifications related to status page changes. This would be a read-only feature: subscribers would not be able to modify monitors, incidents, or any system configuration.

The initial scope would support email notifications only, using the existing SMTP configuration, with the ability for users to subscribe to one or more status pages and receive notifications when incidents or monitor status changes occur.

✔️ Solution

Add an optional self-registration mechanism to status pages that allows users to subscribe via email.

Proposed behavior:

  • Admins can enable or disable self-registration per status page.
  • When enabled, the status page displays a “Subscribe” option.
  • Users enter an email address and must confirm ownership via a confirmation email (double opt-in).
  • After confirmation, users receive email notifications for:
    • Incident created
    • Incident updated
    • Incident resolved
    • Monitor up/down events
  • Each notification email includes an unsubscribe link that immediately stops notifications.
  • Users may subscribe to multiple status pages.
  • Emails can be plain text and should reuse the existing SMTP/email infrastructure.

This approach provides value without exposing any administrative or write access to the system.

Image

Alternatives

  • Rely on external notification systems (RSS feeds, third-party status tools, or custom scripts), which increases operational complexity and reduces usability.
  • Require admins to create notifications, adding extra work for admins and not desirable for public status page consumers.
  • Manual email lists maintained outside of Uptime Kuma, which do not stay in sync with incidents or monitor state changes.

📝 Additional Context

  • This feature is commonly expected in enterprise monitoring and status page platforms.
  • Notification granularity (choosing specific event types) and additional notification channels (Slack, SMS, etc.) are intentionally out of scope for the initial implementation and can be added later.
  • Admin-side management of subscribers (viewing/editing subscriber lists) is also out of scope for this request.
  • If this feature is not a fit for upstream Uptime Kuma, it could be implemented in a fork, but upstream support would be strongly preferred.
Originally created by @catsdev on GitHub (Feb 15, 2026). ### 📑 I have found these related issues/pull requests I found several existing issues and discussions around “self‑registration”, however they are focused on allowing users to register as **Uptime Kuma system users or admins**. This request is different in scope: - It is **not** about granting access to the dashboard or monitors - It is **only** about allowing external consumers of a status page to subscribe to notifications - Subscribers would have **read‑only** access and receive email notifications only I did not find an existing issue that specifically addresses self‑registration for **status page notification consumers**. ### 🔖 Feature description Uptime Kuma provides excellent monitoring and public status pages, but currently there is no way for end users to subscribe to updates directly from a status page. For enterprise and large-scale usage, it would be very valuable to allow users to self-register for notifications related to status page changes. This would be a read-only feature: subscribers would not be able to modify monitors, incidents, or any system configuration. The initial scope would support **email notifications only**, using the existing SMTP configuration, with the ability for users to subscribe to one or more status pages and receive notifications when incidents or monitor status changes occur. ### ✔️ Solution Add an optional self-registration mechanism to status pages that allows users to subscribe via email. Proposed behavior: - Admins can enable or disable self-registration per status page. - When enabled, the status page displays a “Subscribe” option. - Users enter an email address and must confirm ownership via a confirmation email (double opt-in). - After confirmation, users receive email notifications for: - Incident created - Incident updated - Incident resolved - Monitor up/down events - Each notification email includes an unsubscribe link that immediately stops notifications. - Users may subscribe to multiple status pages. - Emails can be plain text and should reuse the existing SMTP/email infrastructure. This approach provides value without exposing any administrative or write access to the system. <img width="650" height="234" alt="Image" src="https://github.com/user-attachments/assets/5bff354e-f13d-44d2-984c-5a749c21259b" /> ### ❓ Alternatives - Rely on external notification systems (RSS feeds, third-party status tools, or custom scripts), which increases operational complexity and reduces usability. - Require admins to create notifications, adding extra work for admins and not desirable for public status page consumers. - Manual email lists maintained outside of Uptime Kuma, which do not stay in sync with incidents or monitor state changes. ### 📝 Additional Context - This feature is commonly expected in enterprise monitoring and status page platforms. - Notification granularity (choosing specific event types) and additional notification channels (Slack, SMS, etc.) are intentionally **out of scope** for the initial implementation and can be added later. - Admin-side management of subscribers (viewing/editing subscriber lists) is also out of scope for this request. - If this feature is not a fit for upstream Uptime Kuma, it could be implemented in a fork, but upstream support would be strongly preferred.
deekerman 2026-02-28 04:12:52 -05:00
Author
Owner

@catsdev commented on GitHub (Feb 15, 2026):

I see #916 comments. I have created what is described here that I can submit relatively soon for comments.

@catsdev commented on GitHub (Feb 15, 2026): I see #916 comments. I have created what is described here that I can submit relatively soon for comments.
Author
Owner

@andrianvaleanu commented on GitHub (Feb 15, 2026):

Building this natively in Kuma is a massive lift because of the subscriber database and verification flows required. Been using Pulsetic (https://pulsetic.com/) for this exact reason since it handles the status page subscriptions and incident alerts out of the box without bloating the core app.

@andrianvaleanu commented on GitHub (Feb 15, 2026): Building this natively in Kuma is a massive lift because of the subscriber database and verification flows required. Been using Pulsetic (https://pulsetic.com/) for this exact reason since it handles the status page subscriptions and incident alerts out of the box without bloating the core app.
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/uptime-kuma#4717
No description provided.