Other software

BackupSentinel has built-in rules for ten backup products. Anything else that can send an email when a backup finishes can still be monitored: a fixed set of keywords reads reports no rule recognises, and a custom rule of your own reads them exactly. For jobs that cannot send email at all, there is a report API.

Set it up

1. Find the email or SMTP notification settings in the backup software. They are usually under notifications, alerts or reporting.
2. Add the client address as a recipient. It is in Settings → Client addresses and on the client's page. See Client addresses.
3. Turn on a report for every run, not only for failures. A product that only emails on failure looks the same as a backup that stopped running, and turns Missing.
4. Let one report arrive. It appears in the Inbox, where Start monitoring creates the backup.

When you add a backup by hand instead, choose Generic SMTP as the Backup source.

Most products without a built-in rule send no job name that BackupSentinel can read. If a client has more than one backup from such a product, give each backup its own address rather than the client address.

The keyword fallback

When no parsing rule recognises an email, BackupSentinel looks for these words, ignoring case:

The order matters:

• The subject is read before the body. If the subject contains any of the words, the body is not read at all.
• Failure beats warning beats success. Within the subject, and then within the body, a failure word wins over a warning word, and a warning word wins over a success word.
• Words match inside other words. "error" matches "errors", "warn" matches "warning" and "success" matches "successful".

If none of the words appears, the email is stored with No result read and the backup's status does not change.

Where the fallback goes wrong

The fallback reads words, not meaning. Check your product's emails for these:

• "0 errors" is a failure. A success report with a summary line such as "Errors: 0" or "0 errors" contains "error", so it reads as Failed. "Warnings: 0" reads as Warning in the same way when no failure word appears.
• "Unsuccessful" is a success. It contains "success". If the report has no failure word elsewhere, a failed run reads as Healthy.
• A subject decides alone. A subject such as "Backup completed successfully" is read as Healthy, even if the body lists failed files.
• Status columns. A table that names every possible result ("Success / Warning / Error") contains all three kinds of word, so it always reads as Failed.

If any of these applies, write a custom rule. A wrong Failed is noise; a wrong Healthy hides a problem, which is why failure words win.

When to write a custom rule

Write a rule when:

• the product's reports trip one of the pitfalls above,
• its success, warning or failure wording is not in the fallback list (for example "OK", "Completed" or "Aborted"),
• you want one client address to cover several of its backups, which needs a job name read from each email,
• you want backup sizes recorded, so a backup that suddenly shrinks shows in Needs attention.

A custom rule matches emails by a Subject pattern, then reads the result from your own Failed, Warning and OK keywords, and optionally a job name and a size. Your rules run before the built-in ones. The quickest way to start is Create rule on one of the product's emails in the Inbox. Parsing rules explains every field and the tester.

Test it

Send a report, or any email from your own mailbox, to the client address and open it in the Inbox. The reader shows which rule read it ("No parsing rule matched" when the fallback was used), the result, and a one-line explanation of what happened.

To check a rule before you rely on it, use Test against a sample email in the rule editor with a real subject and body copied from the product.

Jobs that cannot send email

Scripts, scheduled tasks and tools without email notifications can report through the API instead. Create the backup with Add job, copy its Job ID from the Setup section of its page, and send one request at the end of each run:

curl -X POST https://app.backupsentinel.io/api/v1/jobs/JOB_ID/report \
  -H "Authorization: Bearer bsk_live_..." \
  -H "Content-Type: application/json" \
  -d '{"status": "ok", "size_bytes": 52428800, "duration_seconds": 340}'

The status is "ok", "warn" or "failed". An API report goes through the same steps as an email: it sets the status, opens and closes alerts, and keeps the backup from turning Missing. Owners and admins create keys in Settings → API keys. See Report API for every field and error.

Limits

• The fallback list is fixed. To use other words, write a custom rule.
• The fallback never reads a job name, a size or a duration.
• A product that only emails when something fails cannot be told apart from one that stopped running. Turn on reports for every run.
• The API only accepts reports for backups that already exist. It cannot create a backup or read one.