Most backup products can send an email after every run. Very few of them agree on what that email looks like. When your monitoring tool has no rule for a product, you write one: a short description of how to recognise that product's emails and how to read the result out of them.
A rule is small, but it decides whether a failure is seen. A rule that reads "Errors: 0" as a failure trains everyone to ignore it within a week. A rule that never matches makes the job look silent. This guide goes through writing one carefully, using an invented product called Stashbox for every example.
What a report email needs to contain
Before writing anything, look at what the product actually sends. A report is readable when it has:
- A recognisable subject. A product name or a fixed prefix that appears on every report, whatever the result.
- The result in words. Success, Warning, Failed, or the product's own equivalents. In the subject if at all possible, because the subject is the product's own summary.
- A report for every run, success included. Without success reports, a job that stopped running looks the same as a job that worked. A backup can fail by saying nothing covers why.
- Useful extras. The job name, so one address can receive several jobs, and the amount of data, so you can spot a backup that suddenly shrank.
If the product cannot include a result, no rule will fix that, so check its notification settings first. Then collect real samples: at least one success, one warning and one failure. A test job pointed at a share that does not exist usually produces a failure. Here are two Stashbox samples:
Subject: [Stashbox] Job "FS01-Nightly" finished: Success
Job: FS01-Nightly
Result: Success
Started: 2026-10-05 22:00
Finished: 2026-10-05 23:12
Protected data: 1,284.6 GB
Transferred: 41.2 GB
Errors: 0
Warnings: 0
Subject: [Stashbox] Job "FS01-Nightly" finished: Failed
Job: FS01-Nightly
Result: Failed
Error: target \\nas02\backups is not reachable
Errors: 1
Warnings: 0
The subject pattern
The subject pattern decides which emails the rule handles. It should match every report from the product, whatever the result, and nothing else.
Match on what is stable: the prefix and the product name. For Stashbox that is ^\[Stashbox\] Job . The ^ anchors it to the start of the subject, and the square brackets are escaped with a backslash because they mean something in a regular expression. The same goes for ., (, ), ?, * and + when you mean them literally.
Leave the result word out of the subject pattern, or the rule only ever sees one outcome. Leave the job name out too, unless you want one rule per job.
Two things break subject patterns in practice:
- Mail relays that rewrite subjects. If reports pass through a gateway that adds "[EXTERNAL]" or "FW:" to the front, an anchored pattern stops matching. Drop the
^if that can happen. - Product updates. A new version may say "completed" where the old one said "finished". Match only as much as you need:
^\[Stashbox\] Jobsurvives that change,finished: (Success|Failed)does not.
Keyword lists, and why order matters
The result comes from three keyword lists: failed, warning and OK. A report often contains words from more than one list. "1 of 12 items failed, 11 completed successfully" has both a failure and a success in it, and the honest reading is a failure.
So the lists are checked in order of severity: failed first, then warning, then OK, and the first hit wins. Missing a failure costs far more than a false alarm, so the order leans that way on purpose.
Keyword matching is normally plain containment, not whole words. That has a consequence worth knowing: "success" is found inside "unsuccessful". If the product ever writes "Backup unsuccessful", put "unsuccessful" in the failed list. Because failed is checked first, it wins over the "success" hidden inside it.
Where the keywords are looked for matters as much as the order. A sensible rule checks the subject first, against all three lists, and only reads the body if the subject has no keyword in it. The subject is the product's verdict; the body is detail that mentions errors in passing. The flip side: once the subject has an OK keyword, the body is never consulted. If the product writes "Backup completed" in the subject whatever happened, "completed" must not be in your OK list.
The "0 errors" trap
Look at the Stashbox success report again. It contains "Errors: 0" and "Warnings: 0". With "error" in the failed list, every single report contains a failure keyword.
Here the subject says "Success" and is checked first, so the trap never springs. But plenty of products put a neutral subject on every report, such as "Stashbox job report: FS01-Nightly", and leave the result to the body. Then naive keywords read every report as failed. The mirror image is just as bad: "warning" in the warning list matches "Warnings: 0", every backup turns Warning, and the team learns that Warning means nothing.
The fix is to use the product's own phrases rather than single words:
Failed: result: failed, unsuccessful
Warning: result: warning
OK: result: success
Copy the phrases from real emails, punctuation included. Avoid counts: "errors: 1" catches one error and misses two. In HTML reports the label and value often sit in separate table cells, so the gap between them may be a tab or a line break: one more reason to test with the real email.
Reading the job name
If one address receives reports for several jobs, the rule has to read the job name, or every report lands on the same backup. A job name pattern has one capture group, and whatever it captures becomes the name:
Job:\s*([^\r\n]+)
That reads everything after "Job:" up to the end of the line. Stashbox also puts the name in the subject, between quotes, so Job "([^"]+)" works as well. Pick whichever the product keeps most consistent. The captured name has to be identical on every run, so never capture a date, a counter or a session ID along with it.
Reading the size
A size pattern usually has two groups: the number, then the unit.
Protected data:\s*([\d.,]+)\s*(TB|GB|MB|KB)
Choose the figure that stays steady from run to run. Stashbox reports both the protected data and what was transferred. The transferred figure of an incremental backup swings with how much changed that day, so it tells you little. The protected total moves slowly, which makes a sudden drop meaningful. Small backups are suspicious explains what such a drop can mean.
Watch the number format. "1,284.6" uses a comma for thousands; a product set to a European locale might write "1.284,6" or "1,5 GB" instead. A tool has to guess which separator is the decimal point, and "1,284" could be one thousand two hundred and eighty-four or one and a quarter. Test how your tool reads the product's format before trusting it, with a figure from a real report.
Keep regexes simple and safe
Every pattern runs against every email the rule sees. Some shapes take exponential time on unlucky input, a problem known as catastrophic backtracking: a repeated group whose contents can themselves repeat or alternate, like (\w+\s?)+ or (a|a)*. Good tools refuse such patterns. Better not to write them:
- Match the literal label, then let one character class do the variable part:
Job:\s*([^\r\n]+). - Prefer a negated class such as
[^\r\n]+or[^"]+to.*. It says exactly where to stop. - Never put a
+or*after a group that already contains a quantifier or a|. - Keep it short. A pattern longer than a line is usually trying to do two jobs.
Test on a real email before saving
Paste a real subject and body into the tester and check four things: the subject pattern matches, the result is right, the job name is right and the size is right. Do it for every sample you collected, success, warning and failure. Then paste a report from a different product and make sure your rule does not claim it.
Test again after the product is upgraded. Vendors change report wording without notice, and a rule that stops matching looks exactly like a backup that went quiet.
Writing a rule in BackupSentinel
On the Email parsing page, a custom rule has a name, the product it is for, a subject pattern, an optional description, three comma-separated keyword lists (Failed, Warning, OK, up to 20 keywords each, matched without regard to case), a job name pattern and a size pattern. There is no field for duration. The job name pattern needs a capture group, and group 1 becomes the name. In the size pattern, group 1 is the number and an optional group 2 the unit (TB, GB, MB or KB). BackupSentinel reads both styles. When a number has a comma and a dot, the last one is the decimal point, so "1,284.6" and "1.284,6" both read as 1,284.6. A single comma is a thousands separator when it groups exactly three digits ("1,284" is 1,284) and a decimal comma otherwise ("1,5 GB" is 1.5 GB); several commas are thousands separators. A single dot is always a decimal point, so "1.284 GB" reads as 1.284 GB. Check a real report in the tester if your product writes sizes with a decimal comma.
Keywords resolve exactly as described above: failed beats warning beats OK, and the subject is checked before the body. Patterns can be at most 200 characters, and nested quantifiers such as (a+)+, adjacent ones, and groups that repeat ambiguously are rejected when you save, because the parser would refuse them. Test against a sample email takes a subject and a body and shows whether the subject matches, the status, the job name and the size, using the same rules as the parser.
Your own rules are tried before the library's, and the first match wins. An email that matches a rule but contains none of its keywords is marked No result read and waits in the Inbox under Needs review, rather than being guessed at. To adapt a built-in rule, choose Customize in the library to get an editable copy.
The field reference is in Parsing rules, and Other backup software covers setting up a product without a built-in rule. Parsing rules lists the products that already have one.