Checking Delivery Status

-- one notification
SELECT * FROM pgrelay_notifier.get_status(42);

-- recent failures
SELECT * FROM pgrelay_notifier.list_notifications('failed', now() - interval '1 day');

-- the attempt-by-attempt trail
SELECT * FROM pgrelay_notifier.get_history(42);

get_status() returns the notification's current state — status, recipients, subject, status_detail on failure, provider_ref on success, attempt count, and elapsed time. list_notifications(p_status, p_since, p_limit) filters and paginates across many notifications; get_history(id) returns every attempt recorded for one notification, oldest first.

Reading the status column

See Core Concepts for the full lifecycle diagram. In short:

Status	Terminal?	Meaning
draft	no	Composed, not yet dispatched
pending	no	In the queue, awaiting the Processor
retry	no	Transient failure; another attempt is scheduled
sent	yes	Delivered. provider_ref holds the SMTP Message-ID or Graph request-id
failed	yes	Permanent failure or retries exhausted; status_detail says why
expired	yes	expire_at passed before delivery
invalid	yes	Channel disabled/unregistered at dispatch time

Following up with a provider

If a message shows sent but the recipient says it never arrived, provider_ref is exactly what to quote to your mail provider or Microsoft support — it's the SMTP Message-ID or the Graph API's own request-id for that specific delivery attempt.

Polling vs. watching a specific send

For a one-off "did this send yet" check right after calling send(), get_status() is enough. For anything systematic — a dashboard, an alert on a growing failure rate — query list_notifications() on a schedule, or ask your DBA about the monitoring queries in the DBA Guide.

---