Skip to content

[Self Hosted]: Email status page subscriptions create pending subscriber but do not send verification email #2571

Description

@jiggyjigsj

Summary

When a visitor subscribes to a public status page via email, OpenStatus creates a pending subscriber and returns a verification token, but no verification email appears to be sent.

The codebase already has email verification support via sendEmailVerification(...) and a public /verify/[token] route, but the statusPage.subscribe mutation does not seem to call the email channel after creating the subscriber.

Current behavior

  1. Visitor opens a public status page.
  2. Visitor enters an email in the subscription form.
  3. statusPage.subscribe creates or updates a pending subscriber.
  4. The mutation returns { id, token }.
  5. No verification email is sent to the subscriber.
  6. The subscriber has no way to discover the /verify/[token] URL unless custom code uses the returned token.

Expected behavior

  1. Visitor submits an email subscription request.
  2. Server creates a pending subscriber with a verification token.
  3. Server sends a verification email using the configured email provider.
  4. The email includes the public status page verification link, for example /verify/<token>.
  5. Visitor clicks the link.
  6. The subscriber is marked accepted/verified.
  7. Future status updates are sent only to accepted subscribers.

Why this matters

Without the verification email, self-hosted status page email subscriptions appear successful in the UI but are not actionable for external subscribers. This makes the subscription flow effectively unusable unless deployers add custom logic outside OpenStatus.

Notes

The existing pieces appear to already exist:

  • packages/subscriptions/src/channels/email.ts includes sendEmailVerification(...).
  • The status page app includes a /verify/[token] route.
  • statusPage.subscribe creates the subscriber and returns a token.

The missing piece seems to be wiring the subscribe mutation to send the verification email server-side after creating the pending subscriber.

I'd be happy to attempt a fix with my LLM. Let me know if that's acceptable for this project.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions