Notifications & Alerts

A client's own IT contacts — not BYOVault's operators — are who these emails reach. Every one of them is configured in one place, per tenant, and every one exists to surface a real problem or a real upcoming event before it affects the client.

Where recipients are configured

On a tenant’s Settings → Client Alert Recipients tab, an operator adds the email addresses that should hear about problems or upcoming activity for that specific client. This list is per-tenant, not global — each client’s contacts only ever hear about that client’s own environment.

Not the same list as the operator's own account settings
BYOVault operators have a separate, account-level notification setup of their own, with independent controls for backup, job, tenant, account, and restore events.

It also includes an optional digest email on a daily, weekly, or monthly schedule. That system is scoped to the operator’s own account and is not covered on this page — everything below is about what a client’s own registered contacts receive.

Connection health — every 15 minutes

A recurring check confirms, for every active tenant, that:

  • The backup schedule is actually running.
  • The most recent backup job didn’t fail.
  • Once an hour rather than every cycle: Microsoft 365 access is still authorized and the configured storage destination is still reachable.

If any of these is currently wrong, one combined email lists every current problem.

Resent every 15 minutes for as long as the problem persists
This is a deliberate choice, not a bug: the email keeps arriving on every 15-minute check for as long as something is actually wrong, rather than sending once and stopping. It stops the moment the underlying problem is fixed.

File-server agent has stopped checking in — checked hourly

Every active file-server agent is expected to check in roughly once a minute. An hourly check looks for any agent that has become unresponsive for more than 30 minutes — long enough that a single missed check-in or a brief network blip never triggers it, but short enough to catch a crashed service, a stuck update, or a machine whose backups have silently stopped before a client notices on their own.

If a tenant has one or more agents in this state, one email lists every affected machine, its hostname, its version, and when it was last seen.

This alert never changes anything automatically — it exists purely so a stalled agent gets noticed within the hour instead of relying on someone to realize their backups have stopped.

24 hours' advance notice — checked hourly

A separate, lower-urgency check runs hourly and looks ahead 24 hours across three independent concerns for each tenant. Any that apply are combined into a single email:

  • The tenant’s next scheduled backup run.
  • The tenant’s next scheduled archiving sweep (only for tenants with archiving enabled).
  • Any files about to move into the tenant’s protected retention vault in the next 24 hours (only for tenants with a vault actually provisioned and locked).

Each of the three is tracked independently and only sends once per distinct occurrence — an hourly re-run doesn’t resend the same warning about the same backup or the same batch of files every hour, only when something genuinely new comes into the 24-hour window.

The retention warning is informational, not urgent
Files moving into the vault are never deleted — they’re moved into cheap long-term storage and remain fully backed up and instantly restorable. Only deletion becomes blocked once they land there, for the retention period the tenant chose.

If a client wants a specific file kept out of the vault for a specific reason, that’s not a self-service action. They contact their BYOVault operator directly, who can mark that item preserved from the dashboard before the 24-hour window closes.

Self-service request activity

Separately from all of the above, each stage of a self-service restore request notifies the person who submitted it, and optionally the tenant’s IT contacts. The stages are:

  • Submitted
  • Approved
  • Rejected
  • Completed
  • Failed

See Self-Service Portal for the full request lifecycle. Recipients for this one are configured separately, on the Self-Service tab’s own recipient list, distinct from the Client Alert Recipients list described above.