Alerts and reports
Under Administration → Alerts & reports you decide who is told what, and when. Each tenant has its own rules. Tenant administrators and provider administrators manage them.
Alerts: when something happens
Section titled “Alerts: when something happens”An alert rule sends a message for each event it lists:
| Group | Event |
|---|---|
| Jobs | Backup failed, restore failed, restore completed, archive sync failed, directory sync failed, server or client not reporting |
| Recoverability | Restore check failed (red), restore check needs attention (yellow), restorable again |
| Storage | Storage damage found, storage damage repaired |
| Installation | Update available |
Servers and clients. Server or client not reporting fires when a server has not been in contact for more than 2 hours, or a client has had no good backup for 7 days. Both limits can be set per endpoint, and a client is never treated as silent just because it is switched off at night. The other events cover endpoints too: a failed backup or restore of a server or client raises Backup failed or Restore failed, a failed restore test raises Restore check failed, and a damaged repository raises Storage damage found. An existing rule for these events therefore covers endpoints without a change. See Endpoint backup.
Update available. Restow raises this once per new version for the whole installation, after the update check has been turned on under Settings, Updates. Only provider administrators can put it into a rule: a tenant’s own administrators are not told about your updates. See Updates.
Repeat alerts limits how often the same rule alerts about the same mailbox (or the same job type): every time, or at most every 15 minutes, hour, 4 hours or day. The bell always shows every event, with or without a rule.
Reports: at a point in time
Section titled “Reports: at a point in time”A report rule sends a summary of the last day, 7, 30 or 90 days at a fixed time: daily, weekly on a chosen day, monthly on the 1st, or a cron expression. The time zone is part of the rule. Contents you can choose:
- Backups: success rate and failed items, each with the previous period for comparison.
- Recoverability: the share of mailboxes and OneDrives proven restorable, and how many are protected.
- Failures: the most frequent failure causes.
- Storage: protected data and what it takes after deduplication.
- Restores: how many ran.
The figures are the same ones the Statistics page shows for that period.
Recipients and channels
Section titled “Recipients and channels”- E-mail: any addresses, one per line. Mail goes out through the transport set under Settings → Notification mail (SMTP or Microsoft Graph). Without a transport, the delivery log says so.
- Bell: reports can also appear in the bell of everyone in the tenant. Alerts always do.
- Webhook: a rule can also send to one of the tenant’s webhooks (Integrations), as the signed events
report.alertorreport.summary, for example to an RMM, Teams or a ticket system.
Messages use the rule’s language, or the tenant’s language when none is set.
Test and delivery log
Section titled “Test and delivery log”Send test now (in a rule’s menu) sends a message marked as a test on every channel of the rule. The Delivery log shows every mail, bell entry and webhook with its outcome: queued, sent, failed or skipped, and why. A failed mail is retried after 1, 5, 15 and 60 minutes, then given up.
Recipients from the tenant wizard
Section titled “Recipients from the tenant wizard”The notification recipients chosen when a tenant is created become rules: failed jobs and recoverability at risk as alerts, the weekly report (Business) on Mondays at 07:00. You can change them here like any other rule.
What is recorded
Section titled “What is recorded”Creating, changing and deleting a rule and every test send are written to the audit log. The read state of the bell belongs to the tenant: marking something read marks it read for everyone in that tenant.