Email Alerts
Email alerts are automated downtime and recovery notifications that MonitorUrs sends to your inbox the moment a monitored service fails or comes back online. Each message is delivered over SMTP with an HTML body, supports multiple recipients, and is queued with automatic retries and bounce handling so critical alerts get through.
Last updated: June 2026
Why email alerts matter
Email is the most universal alerting channel there is. Everyone has an inbox, it works on every device, and it leaves a permanent, searchable record of every incident. When a server goes offline at 3 a.m. or a website starts returning errors, an email alert lands in front of the right people without requiring them to install an app, join a channel or share a phone number. For many teams it is the natural place where on-call notifications, ticketing systems and audit trails all come together.
Email is also resilient. Because it is built on store-and-forward delivery, a transient network problem on either end does not silently drop the message — the alert is queued and delivered when the path clears. MonitorUrs leans into that strength with its own retry and bounce-handling logic, so a single hiccup never means a missed downtime notification.
How email alerts work in MonitorUrs
When a monitored probe, server or metric crosses an alert condition, MonitorUrs composes an email and hands it to a central outgoing-message queue rather than sending it inline. A background worker drains that queue continuously — roughly every 15 seconds — which keeps alert delivery fast while decoupling it from the monitoring checks themselves. The flow looks like this:
- Trigger: a probe failure threshold is reached, a server is detected offline, or a metric crosses a threshold rule, and MonitorUrs builds an alert email.
- Queue: the message is placed on the central outgoing-message queue and given an initial state of not-sent.
- Send: the queue worker picks it up — about every 15 seconds — and transmits it over SMTP, or via the Google Gmail API for the MonitorUrs domain.
- Confirm or retry: on success the message is marked sent-ok; on a transient failure it is marked will-retry and attempted again, up to a configurable attempt limit.
- Recover: when the service is restored, MonitorUrs automatically queues a recovery email so the same recipients know the incident is over.
What an email alert contains
Every alert is sent with an HTML body, so the details are laid out clearly rather than crammed into plain text. That makes it easy to scan what failed, when, and why at a glance, straight from your inbox. Alerts can be addressed to multiple recipients at once — simply enter several addresses separated by semicolons — and each address is validated before it is accepted so a typo never silently breaks delivery.
Because addresses are semicolon-separated and validated, you can route a single alert to a whole on-call group, a shared team inbox and an individual owner together, knowing that an invalid entry will be caught instead of quietly dropping the message for everyone.
Reliable delivery: retries and bounce handling
An alert is only useful if it actually arrives. MonitorUrs treats delivery as a first-class concern: every message moves through the central outgoing-message queue, processed continuously, and carries an explicit state so nothing is lost in the gap between "tried" and "delivered." If a send fails for a transient reason, it is retried automatically up to a configurable attempt limit before it is given up on.
| Message state | What it means |
|---|---|
| not-sent | The message is queued and waiting for the next pass of the outgoing-message worker. |
| will-retry | A send attempt failed for a transient reason; MonitorUrs will try again, up to the configured attempt limit. |
| sent-ok | The email was accepted for delivery successfully and no further action is needed. |
| final-fail | The attempt limit was reached without success, so the message is marked as permanently failed. |
Bounce handling protects both your deliverability and the alerting system itself. If a mailbox turns out to be unavailable, MonitorUrs temporarily bans that address for about 24 hours instead of hammering it with repeated attempts. This avoids piling up failures against a dead address and keeps the sending reputation clean so that legitimate alerts are not penalised as spam.
When email alerts fire
MonitorUrs sends email alerts on the events that actually matter, and follows up automatically when things return to normal:
- Probe failures — once a probe has failed the configured number of consecutive times, an alert is triggered, filtering out one-off blips.
- Server offline — when a monitored server is detected as offline, an alert goes out so you can react before users do.
- Metric threshold rules — when a server metric crosses a threshold rule you have defined, MonitorUrs raises an alert.
- Automatic recovery — when the service is restored, a recovery email is sent automatically to close the loop.
Because alerts only fire after the failure threshold is reached, the email channel stays quiet during transient noise and meaningful when it does light up. Every one of these events also feeds your incident history, so the email in your inbox is backed by a permanent record.
Email vs Telegram vs SMS
Email is one of three alerting channels in MonitorUrs, and they complement each other. Many teams enable all three: email for detail and record-keeping, Telegram alerts for fast team chat, and SMS alerts for the can't-miss escalations.
| Channel | Best for | Strengths |
|---|---|---|
| Detailed alerts and audit trails | HTML body, multiple recipients, retries and bounce handling, permanent searchable record. | |
| Telegram | Fast team and channel chat | Instant push to a person or shared channel through the MonitorUrs bot. |
| SMS | Critical, can't-miss escalation | Reaches a phone even without internet, ideal for waking on-call staff. |
Common use cases
- On-call teams — send a single alert to a whole on-call group using semicolon-separated recipients so nobody is left out.
- Shared inboxes and ticketing — route alerts to a support or NOC mailbox so each incident automatically becomes a trackable item.
- Compliance and audit — keep a permanent, timestamped email trail of every downtime and recovery event for reporting.
- Agencies and managed services — notify both your team and the client owner on the same alert, with bounce handling guarding deliverability.
How email alerts fit the bigger picture
Email alerts are one part of a complete monitoring and notification strategy. They work alongside Telegram and SMS alerts to make sure a notification always reaches the right person, while the real-time status dashboard and your incident history turn each alert into a live view and a permanent record. Together they give you both the immediate ping and the long-term context in one platform.
Frequently asked questions
How does MonitorUrs send email alerts?
MonitorUrs sends email alerts over standard SMTP, and uses the Google Gmail API for its own domain. Every alert is queued through a central outgoing-message queue that is processed continuously.
Can I send email alerts to more than one recipient?
Yes. Each alert can go to multiple recipients by entering several email addresses separated by semicolons. Every address is validated before it is accepted, so a typo does not silently break delivery.
What happens if an email alert fails to send?
Messages flow through an outgoing-message queue that is processed about every 15 seconds. If a send fails it is automatically retried up to a configurable attempt limit, with each message tracked through states such as not-sent, will-retry, sent-ok and final-fail.
How does MonitorUrs handle bounced or invalid email addresses?
Bounce handling is built in. If a mailbox is unavailable, the address is temporarily banned for about 24 hours so MonitorUrs does not keep retrying a dead address and risk being flagged as spam.
When are email alerts triggered?
Email alerts fire on probe failures after the configured consecutive-failure threshold, when a server is detected offline, and when a server metric crosses a threshold rule. An automatic recovery email is sent when the service is restored.
Are email alerts formatted as HTML?
Yes. Email alerts support an HTML body, so the notification is readable and clearly structured rather than plain text, making it easy to scan the incident details at a glance.