The email to worry about is the one that never arrived.
Backup reports, scheduled jobs, system alerts: dozens of emails a day that should arrive. Then there are the sites that must answer, and the backups that write to nobody. Mail Monitor watches all three: the email, the service, the job, and tells you when one is missing.
Expected today
- OK3
- ERROR1
- MISSING1
- PENDING1
Veeam nightly backup
OKEmail backup@
02:14
Cron invoice export
ERROREmail system@
03:02
Veeam North branch backup
MISSINGEmail backup@
due 06:00
acme.com home page
OKService HTTPS
200 in 180 ms
RDP terminal server
OKService TCP 3389
24 ms
restic warehouse NAS
PENDINGAPI heartbeat
by 20:00
Dozens of status emails. Nobody reads them all.
Backups, scheduled jobs, alerts, automated reports: plenty of systems write to you when they finish. The problem is not the email that says “Failed”: sooner or later, someone notices that one.
The problem is the email that never arrives at all. The job never started, the agent died, the server is off. No error, no red line: just silence.
And it is the same silence when the site goes down, when the RDP port stops answering, when the backup script on the NAS quietly stops running. Different systems, same signal: none at all.
“No news is not good news. It is the first thing you should be checking.”
Three ways to find out. One dashboard.
Not every system speaks the same way: some write to you, some answer if you ask, and some say nothing to anyone. Mail Monitor treats them all as the same object: a check with an outcome.
- IMAP
- read-only
The ones that write to you. Connect the mailbox over IMAP, always read-only. Then describe the email you expect and the window it must arrive in: sender, must contain “Success”, must not contain “Failed”. You can build the rules from an email you have already received.
Services
- HTTP
- TCP
The ones you can ask. HTTP checks using GET, HEAD or POST with a body, an expected status and filters on body and headers; or plain TCP on a port: RDP 3389, SQL 1433, SSH 22, SMTP 25. One service groups several addresses: if they go down together, you get a single alert. On the full plan, a response-time threshold too.
API checks
- Heartbeat
- full plan
The ones that talk to nobody. Here the backup calls a URL of ours when it finishes: if the call does not arrive within the expected window, the check turns MISSING. A dead man’s switch for restic and borg scripts in cron, NAS boxes, nightly pg_dumps. The URL is healthchecks.io-compatible: /start times the job, /fail or a non-zero exit code reports the failure. Ready-made snippets for curl, PowerShell, borgmatic, Duplicati and Proxmox Backup Server.
Four steps. Then it takes over.
Connect the source
The IMAP mailbox that receives the emails to watch, the address of the service to probe, or the URL your job will call when it finishes. Mailboxes are always opened read-only: nothing is marked, moved or deleted.
Describe what you expect
“An email like this, every day by 08:00.” “This address, every 5 minutes.” Every N hours, daily, weekly or monthly, with a cut-off time and a tolerance, because a minute late is not a failure. For calendars that do not fit, the full plan takes a cron expression.
Set the rules
Required and forbidden words in subject and body, expected HTTP status, conditions on the response content. On the full plan, thresholds on numbers as well: response time, job duration, a figure written in the email. All testable right away: email rules against the last 50 messages already fetched, services with “Test now” even before you save.
Watch the traffic light
Every expectation becomes an outcome: OK, ERROR or MISSING. Instant alert, daily digest, or dashboard only. Acknowledge what you are already handling, pause what is down for maintenance. And if you want, the alert also reaches your end customer, from your SMTP server and with your logo.
Here, colour means something.
Everything else is black and white. Green, red and amber appear only where they carry information: the state of a check. No decorative colour, no noise. One glance tells you what to look at.
OK
The email arrived within the expected window, the service answered as it should, the job checked in. Everything went as planned.
ERROR
The signal arrived, but it is the wrong one: error words in the email, an unexpected HTTP status, a closed port, a job reporting its own failure. Something ran, and something went wrong.
MISSING
The window closed and nothing arrived. This is the case nobody sees today, and the reason this tool exists.
PENDING
The window is still open. Computed on the fly, never a false alarm ahead of time: we wait until the tolerance runs out.
Little to configure, nothing to forget.
Detects what never arrives
The heart of the tool: if nothing shows up within the expected window, the state turns MISSING and the alert goes out.
Content rules
Sender, required and forbidden words as chips, including on text extracted from HTML emails. Build them from an email you have already received, and every outcome states its reason. The same conditions apply to a service response.
Thresholds on numbers
“Job succeeded in # milliseconds”: put # where the number goes and set the limit. Works on emails, HTTP and TCP response times, and job duration. Each threshold is either an error or just a warning. Full plan.
Schedules, windows and cron
Every N hours, daily, weekly or monthly. Start and cut-off time, chosen days, tolerance in minutes: whatever arrives late is “late”, not broken. On the full plan, a cron expression too, with a preview of the next runs.
HTTP and TCP services
GET, HEAD or POST with a body, expected status (200, 200|204, 2*), filters on body and headers, or simply a port that must open. With “Test now” before you save.
API checks
The job calls a URL when it finishes; if it never calls, it is MISSING. healthchecks.io-compatible: /start times the job, /fail and the exit code report a failure. Ready-made snippets, Duplicati included. Full plan.
A dashboard that answers first
A banner at the top says whether anything is wrong. Below it, a tab per source, a “problems only” switch and a table sorted by severity. On a phone, each row becomes a card.
Groups, pause and hidden rows
Sort checks and services into a colour-coded group tree by dragging them. A pause, until a date or until you lift it, can cover a whole group: no MISSING, no alerts. And each user hides the rows they do not need.
One alert, only when it counts
A consecutive-error threshold before anything fires, a single email per service even when several addresses go down, and “acknowledged”, with a written note, to silence what you are already handling.
Alerts for your customers
From your SMTP server, with your logo and your colours. Address book, templates with placeholders (customer, check, state, reason…), live preview and test send, a recovery email when it is back to OK, and a cooldown. Your customer sees your name, not ours.
Reliability and history
30-day percentage per check, a 7/30/90-day trend chart, CSV export and a printable PDF report. If a mailbox was disconnected for a while, “Recheck” re-reads the latest emails and fills the gaps.
We watch your email. We never touch it.
A monitor should be invisible to what it observes. The less data we keep, the less surface we expose. By principle, not by default.
Read-only IMAP
We never mark as read, never move, never delete. The mailbox stays exactly as it is: we only read it.
Credentials encrypted at rest
IMAP passwords, service credentials and your SMTP password are encrypted with AES-256-GCM. Never in clear text in the database, the logs or the API responses.
Multi-organisation isolation
Every query is filtered by organisation from the token, never from the request payload. One customer’s data never comes near another’s.
Two-factor authentication
TOTP with an authenticator app: optional for users, mandatory for the system administrator. No exceptions.
Revocable sessions
See where you are signed in and sign out other devices in one click. Every sign-in from a new address triggers an email, with a link that closes everything.
Targets kept in check
Private addresses and cloud metadata endpoints are blocked, redirects are not followed, and repeated sign-in attempts are throttled.
The short answers.
What is Mail Monitor?
Mail Monitor is a SaaS that checks the things you expect and do not always get: recurring emails (backup reports, scheduled jobs, alerts, automated confirmations), services that must answer, and jobs that check in over an API. It tells you when something is missing.
How does it notice a missing email?
You define a check with an expected schedule (hourly, daily, weekly or monthly) and a cut-off time. If the window plus the tolerance expires and no email matching the rules has arrived, the check turns MISSING and the notification fires.
Is it only for backups?
No. Backups are the most common example, but it works for any recurring email (automated reports, cron results, antivirus alerts, e-invoicing confirmations) and for any service or job you need to know is alive.
What are service checks?
Checks we run ourselves, at a regular interval: an HTTP call with an expected status and filters on the response body, or opening a TCP port (RDP 3389, SQL 1433, SSH 22…). A service groups several addresses under one name: if they go down together you get a single alert, not one per address.
What about backups that send no email at all?
That is what API checks are for: your job calls a URL of ours when it finishes, and if the call does not arrive within the expected window the check turns MISSING. The URL is healthchecks.io-compatible, so borgmatic speaks it natively; for curl, PowerShell (Veeam, Scheduled Tasks), Duplicati and Proxmox Backup Server the snippet is ready in the interface.
How do I connect the mailbox?
Over IMAP, with the server address, a username and a password (or app password); the connection is verified before saving. Any provider that offers IMAP access with a password or app password will do. The mailbox is always opened read-only: we never mark as read, move or delete anything.
Is it compatible with healthchecks.io?
Yes, API checks use the same URL shape: a plain call when the job finishes, /start when it begins, /fail on failure and the exit code appended to the address, over HEAD, GET or POST. If you already use healthchecks.io you only change the domain, and tools that support it, borgmatic for one, work unchanged. The body of a POST call is evaluated with the same “must / must not contain” rules as emails.
Can I set thresholds on duration, response time or numbers written in an email?
Yes, on the full plan. Write the line as it appears, with # in place of the number (“Job succeeded in # milliseconds”), and set the limit. It works on email subject and body, on the body, headers and response time of HTTP checks, on TCP connect time, and on the duration of jobs that call /start. Each threshold is either an error, which fails the check, or a warning, which leaves the outcome as it is and shows up in the reason and, if you want, in an email.
How do I suspend a check during maintenance?
Pause it: until a date, after which it resumes on its own, or until you lift the pause. While paused, no checks run, nothing turns MISSING and no alerts go out. A pause applies to a check, a service or a whole group, and in that case everything inside the group inherits it.
Can I organise checks by customer or by site?
Yes, with groups: a tree as deep as you like, each group with its own name and colour, where you drag checks and services. Deleting a group does not delete what is in it. Each user can also hide the rows that do not concern them: they drop out of that user’s counts, but are still checked and still alert.
Can I alert my own customers?
Yes. Each organisation can configure its own SMTP server, logo and colours, so end-customer alerts go out in your name. There is a contact address book and reusable templates with placeholders (customer, check, state, date, reason…), with a live preview and a test send to any address. For each check you pick the recipients and the template for ERROR, MISSING and back-to-OK, plus a cooldown so the same alarm is not repeated endlessly.
Is my data safe?
IMAP passwords and service credentials are encrypted at rest with AES-256-GCM and never appear in clear text. Every organisation is isolated from the others, access can be protected with two-factor authentication, and sessions can be revoked at any time.
What kind of notifications does it send?
Instant alert per event, daily digest, or dashboard only. You can require N consecutive failures before anything fires: on a check that runs every minute, a reboot or a deploy should not wake anyone up.
Is there a free plan?
Yes, and it does not expire: one mailbox, two email checks, one service with two checks and one user. API checks and larger volumes are part of the full plan.
What does the full plan add?
No limits on mailboxes, checks, services and users, plus three reserved features: API checks, cron-expression scheduling and numeric thresholds. Everything else (rules, dashboard, groups, pause, notifications, customer alerts, reports) is identical on both plans. The free limits only apply to what you create: nothing is lost when you move between plans.
How long is the history kept?
Outcomes of email and API checks are kept with no expiry. Outcomes of service checks, which may run every few minutes, are kept for 90 days. You can export the history to CSV at any time.
Try it on your own backups.
Connect a mailbox and define your first check in minutes. The free plan never expires: one mailbox, one service, and the backup you cannot see today, you will see tomorrow.