Notifications, reports and verification
The eleven notification events and which are on by default, who receives them, the alert threshold for deleted items, and how the daily verification run works.
The eleven events
Only what is switched on is sent.
| Event | Meaning |
|---|---|
| A backup failed or is overdue | a run failed or did not happen |
| Unusually many items deleted at Microsoft | a spike above the alert threshold |
| A restore failed | the run aborted |
| A restore was started | somebody initiated a run |
| A restore succeeded | the run finished |
| A restore succeeded with warnings | finished, but not complete |
| An export is ready | the file is available for retrieval |
| New data sources discovered | discovery found something |
| A data source was backed up for the first time | the initial run completed |
| Daily summary | collected report on the previous day |
| A Microsoft tenant was added or removed | an organisation changed |
Three are on by default: failed backup, unusually many deletions, failed restore. Precisely the events that call for action.
The start of a restore cannot be switched off. Writing back alters data in your Microsoft tenant; whoever initiates that is worth a notification, and before the run completes. Were the event switchable, a restore could be carried out unnoticed.
Who receives notifications
Without an entry they go to the owners and administrators of the account. With an entry, exclusively to the addresses listed — the default is then dropped, it does not apply in addition.
The setting applies per Microsoft organisation. Anyone running two organisations can set separate recipients for each.
Alert threshold for deleted items
A single deletion at Microsoft is normal and not worth a notification. Only the spike is reported: by default from 250 deleted items of one protection unit between two runs.
Setting the threshold too low produces a flood in which the one case that matters is lost.
The daily verification run
Once a day Conbool draws a sample from the stored content, decrypts it and checks that the items can be read. The result appears under Verification, together with the age of the last sample.
The run additionally checks the audit log's hash chain. If a stored hash does not match its content, that is reported: either an entry was altered, or the hash computation itself has changed.
A green verification run is the basis for the annual check under the Terms. See Verifying restorability.