Which messages are sent
UpBastion queues a downtime email when a second consecutive failed check opens an incident. It queues a recovery email when one successful check closes that incident. It also queues a TLS warning when an observed certificate expiry is within 14 days and has not already been warned about for that monitor.
A first unconfirmed failure does not send an email. Pausing a monitor or changing its URL closes its incident without sending a recovery message. Read incidents and TLS certificates for those event rules.
The recipient
Monitoring notifications go to the account's current verified primary email address. UpBastion synchronizes that address from Clerk on authenticated account activity and account-update webhooks. The sender checks the current saved address again before delivery, so a queued alert can follow a later email change once it is synchronized.
There are no per-monitor recipients, mailing lists or alternate alert channels. Verify your primary email through account settings. The dashboard displays a notice when no verified primary email is available.
If an incident opens while no verified email is saved, a downtime email is not queued for that event. Adding an address later does not retroactively generate the missing notification.
Delivery and retries
An event is saved to a database-backed mail queue. A separate worker loop sends messages through SMTP. Monitoring can continue while a temporary email failure delays delivery.
Failed deliveries are retried with increasing delays, up to 10 failed attempts. The maximum retry delay is one hour. The SMTP server accepting a message does not guarantee that it lands in your inbox: recipient filtering, spam folders and downstream delivery can still affect arrival.
Delivery is at least once. A process interruption after SMTP acceptance but before the queue is marked sent can cause a duplicate message. A stable message identifier is used for retries, but not every receiving mail system deduplicates it. Do not treat a duplicate as proof of a second incident.
When an email is missing
Check that the monitor has a confirmed incident rather than a single failed observation.
Confirm your primary email is verified and correctly entered in account settings.
Look for the dashboard's email-delivery notice.
Check spam, quarantine and mail rules for the message.
Compare the incident and recovery times: mail can arrive later than the observation.
There is no user-facing mail delivery log, resend button or test-email button. Contact support with the monitor name, URL, approximate event time and expected recipient. Do not send account passwords or authentication tokens.
What an email contains
Downtime and recovery messages include the monitor name and full monitored URL. Downtime mail includes the observed error; certificate mail includes the expiry date. Do not place confidential information in monitor names or URL query strings.
Sent and permanently failed queue records are removed by daily cleanup when they are older than 30 days. Copies already delivered to your mailbox remain under your email provider's controls. The privacy policy explains the data involved.