Monitoring & Alert Configuration
BYOVault already runs a set of recurring checks against every active tenant and emails a real problem or a real upcoming event the moment it finds one. The only variable left in an operator's control is who those emails actually reach — and getting that one setting wrong quietly turns a working alert system into one that nobody sees.
What is already being checked, and how often
The full cadence and trigger conditions for every client-facing alert are documented in Notifications & Alerts and are not repeated in full here. In summary, three checks currently run against every tenant:
- A connection-health check runs every 15 minutes per tenant and is resent on every 15-minute cycle for as long as the underlying problem persists.
- A separate hourly check looks for any file-server agent that has stopped checking in.
- A third hourly check gives 24 hours’ advance notice of a tenant’s next scheduled backup, next archiving sweep, or files about to move into a locked retention vault.
All three are real, currently-running checks, not aspirational descriptions.
Who these alerts actually reach
Every one of these checks sends to the same place: the tenant’s own Client Alert Recipients list, configured on that tenant’s Settings tab.
This list is per-tenant, not global — it is the only address book BYOVault consults when a specific client’s backup schedule stops running, a job fails, Microsoft 365 access is revoked, a file-server agent goes quiet, or a retention window is about to close for that client’s data.
Configure this list to a real, monitored distribution list for the client’s IT function — a shared mailbox or group alias the client’s team actually watches — rather than one named individual’s personal inbox.
These alerts are time-sensitive by design: a revoked Microsoft 365 connection or a stopped backup schedule is a live gap in the client’s protection for as long as it goes unnoticed. A single person’s inbox is a single point of failure against vacations, role changes, and staff turnover on the client’s side.
The file-server stale-agent check is the one exception: if a tenant has no recipients configured, it falls back to the operator’s own configured admin address so a stalled agent is never silently unreported. The other two checks have no equivalent safety net.
Populating this list for every tenant at onboarding, rather than leaving it for later, is the only way to guarantee all three checks actually reach someone.
Do not confuse this with the operator's own notification settings
Every BYOVault operator also has a separate, account-level notification setup of their own — independent controls for backup, job, tenant, account, and restore events, plus an optional digest email on a daily, weekly, or monthly schedule.
That system is entirely distinct from Client Alert Recipients: it is scoped to the operator’s own account and reflects what the operator personally wants to hear about across every client they manage, not what a specific client’s own IT contacts should be told about their own environment. See Operator Notifications & Digests for that separate configuration.
When bringing on a new client, treat these as two distinct setup steps rather than one. Configuring the operator’s own digest preferences does nothing to populate a new tenant’s Client Alert Recipients list, and the reverse is equally true — adding a client’s contacts to their own tenant does not surface anything in the operator’s personal digest unless the operator has separately opted into those event categories.
Confirming both are set correctly, for every new tenant, closes the gap the empty-list behavior above creates.
For the recipient-configuration mechanics themselves, see Client Alert Recipients. For the exact trigger condition, cadence, and recipient list for every individual notification type, see the Notification Reference Table.