Alert module

The alert module notifies people when backups fail or when equipment has not been backed up for too long. This page explains how alerts work, how to set them up, and how to monitor them day to day.

What The Alert Module Does

OT Backup raises alert events based on rules you configure. Each rule watches for one condition and delivers notifications through one or more delivery actions — typically an email sent over SMTP.

There are three alert types:

Use Stale backup warning and Stale backup together to get an early warning (for example after 7 days) and an escalation (for example after 14 days).

For stale checks, the age of the equipment is measured from its last successful backup. Equipment that has never been backed up is measured from the date it was created, so new equipment will also raise stale alerts if it is never backed up.

How Alerts Flow

flowchart TD
    A[Backup job fails] --> C[Alert event created in queue]
    B[Evaluation job runs every 5 min<br/>checks stale thresholds] --> C
    C --> D{Processor job runs every 1 min<br/>SMTP enabled?}
    D -- No --> E[Events stay pending in queue]
    D -- Yes --> F[Send email to default address<br/>recipient lists as BCC]
    F -- Success --> G[Event marked Sent or removed]
    F -- Failure --> H{Max attempts reached?}
    H -- No --> I[Retry after delay]
    H -- Yes --> J[Event marked Failed<br/>manual retry possible]

Two background jobs run inside the API service when alerts are enabled:

• Alert evaluation (every 5 minutes) — checks all enabled stale-backup rules against your equipment and creates or clears alert events. If equipment gets a successful backup again, its pending stale alerts are removed automatically.
• Alert processor (every 1 minute) — sends pending SMTP alert events as emails, in batches.

Backup failed events are created immediately when a backup job fails; they do not wait for the evaluation job.

Setting Up Alerts

Everything is configured from the Configuration page. Follow these steps in order.

1. Create an SMTP account (optional)

If your mail server requires authentication, create an account with the SMTP username and password on the Accounts tab. The alert module reads the credentials from this account — never put passwords in the SMTP settings themselves.

2. Configure SMTP settings

On the Settings tab, fill in the SMTP group:

When SMTP enabled is turned off, alert events still queue up — they are sent once SMTP is enabled again.

3. Enable the alert module

Also on the Settings tab, the Alert group controls the background jobs and retry behavior:

4. Create recipient lists

On the Alerts tab, add one or more recipient lists — reusable groups of email addresses (for example "Maintenance team" or "Line 3 engineers"). SMTP delivery actions send to these lists as BCC recipients, so recipients do not see each other's addresses. The Default to address from the SMTP settings is the visible To recipient.

5. Create alert rules

Still on the Alerts tab, add a rule:

1. Click Add Rule, give it a name and pick the alert type. Stale types require a threshold days value.
2. Save the rule, then add one or more delivery actions:
   • Email delivery (SMTP) — select which recipient lists receive the email
   • Integration Service — hands the event over to an external integration service (such as the Maximo integration) instead of sending an email
3. Both rules and individual actions can be enabled or disabled without deleting them.

The alert type of a rule cannot be changed after it is created — create a new rule instead.

Using The Alert Queue

The Alert queue section at the bottom of the Alerts tab shows every alert event and its delivery status:

For Failed events you can:

• Retry — resets the event so the processor picks it up again
• Mark as processed — removes the event without sending

Both actions are also available as bulk operations when selecting multiple rows. Use the Show sent rows switch to include already-delivered events, and the search field to filter by rule name, source, or error text.

The tab header shows summary chips: total rules, enabled rules, recipient lists, and the number of failed alerts.

What The Emails Contain

Alert emails are generated automatically and include:

• A subject describing the alert and the affected equipment, for example Stale backup for Robot-14
• Equipment details: name, description, and location
• A link to the equipment page in OT Backup so the recipient can open it directly
• The last successful backup timestamp, status, storage path, and who triggered it
• The threshold days for stale alerts

Important To Know

• Alert events are only sent while both Alert enabled and SMTP enabled are turned on; otherwise they wait in the queue
• Stale alerts clear themselves automatically when the equipment gets a successful backup or when the rule/action is disabled
• Successfully sent Backup failed events are removed from the queue; stale events remain visible as Sent
• Recipient list addresses are always sent as BCC
• Duplicate alerts are not created — one event exists per rule, action, and equipment (or failed job) combination
• Viewing the Alerts tab requires configuration view permission; creating and editing rules, lists, and queue actions requires configuration edit permission

Do not put passwords in the SMTP host, address, or display-name fields. Store SMTP credentials only on the selected account.