Subscriber notification events

The notification worker reads from pgmq.notification_outbox and fans out to confirmed subscribers on the affected page. The dispatch matrix below lists which event types trigger subscriber email and which do not.

Trigger matrix

Event	Triggers subscriber email
`incident.created`	No (draft state).
`incident.published`	Yes.
`incident.updated`	No (avoids notification spam on minor edits).
`incident.message_added`	Yes.
`incident.resolved`	Yes.
`incident.deleted`	No.
`maintenance.scheduled`	Yes.
`maintenance.starting_soon`	Yes (1h pre-warn).
`maintenance.started`	No (the starting_soon mail covered it).
`maintenance.completed`	Yes.
`maintenance.canceled`	Yes.

Filter scopes

When a subscriber has rows in subscriber_filters, the dispatch only fires when at least one of the incident's affected services or metrics intersects the filter list. Subscribers with no filters receive every relevant event for the page.

Customer-scoped incidents

Incidents with rows in update_customer_visibility are scoped: only subscribers tied to one of the listed customers receive notifications. The MVP customer-binding model on subscribers is still under design; today, customer-scoped incidents skip subscriber dispatch entirely. The webhook layer is unaffected — outbound webhook subscribers always receive every event their subscription opted into, regardless of customer scoping.

Per-attempt audit

Each delivery attempt writes one row to subscriber_deliveries:

id              uuid
subscriber_id   uuid
event_type      text
event_id        uuid
status          text   ('ok', 'error', 'skipped')
status_code     integer (Resend response, when applicable)
error           text   (truncated body on error)
attempted_at    timestamptz

The console Subscribers view exposes the most-recent attempt per subscriber for triage.