Notifications | Zerobyte Docs

Zerobyte's notification system has two layers:

A destination is a reusable delivery channel such as Slack, SMTP, ntfy, or a webhook.
A backup schedule assignment decides which events should be sent to which destination.

You create destinations under Notifications. You route them per backup schedule from the backup details page.

How notifications work in Zerobyte

Destinations are organization-scoped.
Sensitive destination fields are encrypted before storage.
Disabled destinations stay saved, but Zerobyte skips them when sending notifications.
The Test button sends a generic test message for that destination.
Per-schedule routing supports four events: start, success, warning, and failure.

Create destinations once, then reuse them across as many backup schedules as you want.

Supported destination types

Type	Best for	Key fields
`Email (SMTP)`	Existing mail infrastructure, multiple recipients, ticketing aliases	SMTP host, port, sender, recipients, optional auth, TLS
`Slack`	Team chat channels	Webhook URL, optional bot username, optional icon emoji
`Discord`	Server channels or threads	Webhook URL, optional username, optional avatar URL, optional thread ID
`Gotify`	Self-hosted mobile or desktop push	Server URL, app token, priority, optional path
`ntfy`	Lightweight publish-subscribe notifications	Topic, optional server URL, optional auth, priority
`Pushover`	Personal mobile alerts	User key, API token, optional devices, priority
`Telegram`	Group or direct chat notifications	Bot token, chat ID, optional thread ID
`Generic Webhook`	Arbitrary HTTP endpoints and automation systems	URL, method, headers, content type, optional JSON template keys
`Custom (Shoutrrr URL)`	Power users or services not exposed by the built-in forms	Raw Shoutrrr URL

Outbound HTTP notification destinations must use an origin listed in WEBHOOK_ALLOWED_ORIGINS. This applies to Generic Webhook, Gotify, self-hosted ntfy servers, and Custom Shoutrrr URLs that resolve to a custom HTTP endpoint.

Which type should I use?

Choose Email when you already trust an SMTP relay and want easy fan-out to multiple recipients.
Choose Slack or Discord when backup events belong in a shared team room.
Choose Gotify or ntfy when you prefer self-hosted push.
Choose Pushover or Telegram when you want fast personal alerts on a phone.
Choose Generic Webhook when another system expects a normal HTTP request.
Choose Custom (Shoutrrr URL) when the built-in types are close but not flexible enough, or when you need a different Shoutrrr-supported service entirely.

Create a destination

Open Notifications in the sidebar.
Click Create Destination.
Pick the notification type.
Fill in the type-specific settings.
Save the destination.
Open the destination and use Test before attaching it to production schedules.

The type is effectively fixed after creation in the current UI, so create a new destination instead of trying to repurpose an existing one from Slack to Email or similar.

Route notifications per backup schedule

Open the backup schedule you want to configure.
In the Notifications section, click Add notification.
Select an existing destination.
Choose which events should trigger that destination.
Save the backup schedule notification settings.

Each assignment is independent. One schedule can send failures to Email, warnings to Slack, and successes nowhere.

Backup event meanings

Event	When Zerobyte sends it	What is included
`start`	The backup begins running	Volume name, repository name, and schedule name
`success`	The backup completes cleanly	Volume, repository, schedule, and backup summary details when available
`warning`	The backup completes with warnings instead of a clean success	Success details plus warning text when available
`failure`	The backup fails validation or execution	Volume, repository, schedule, and the error text

Type reference

Use Email when you want alerts to go to people, shared mailboxes, or downstream systems that already process email.

Fields

SMTP Host
SMTP Port
Username and Password (optional)
From Address
From Name (optional)
To Addresses
Use TLS

Notes

To Addresses is a comma-separated list in the UI.
TLS is a simple yes or no toggle.
SMTP authentication is optional because some relays accept trusted network senders.

Example

Type: Email (SMTP)
SMTP Host: smtp.example.com
SMTP Port: 587
Username: alerts@example.com
Password: <smtp-password>
From Address: alerts@example.com
From Name: Zerobyte Alerts
To Addresses: ops@example.com, backups@example.com
Use TLS: On

Practical routing patterns

Goal	Suggested routing
Only wake someone up for real problems	`failure` to Email or Pushover
Keep the team informed without noise	`warning` and `failure` to Slack or Discord
Audit every run	`start`, `success`, `warning`, and `failure` to Email or Generic Webhook
Mobile-first personal alerting	`failure` to Telegram, ntfy, Gotify, or Pushover
Feed another incident or workflow system	`failure` and optionally `warning` to Generic Webhook

On this page