Notifications#

DUMB includes an optional backend notification utility for sending health and operational events even when no browser is open. It is separate from the browser-local alert banners on the Metrics page.

Notifications are disabled by default.

What it provides#

• Multiple named notification destinations
• Apprise URLs for Discord, ntfy, Gotify, Telegram, email, Slack, Home Assistant, and other supported services
• Generic JSON webhooks
• Per-destination event, severity, and service routing
• Persistent queued delivery and history under /config/notifications
• Exponential retry with a configurable attempt limit
• Per-event cooldown suppression
• Recovery notifications when monitored pressure clears
• Manual messages and destination tests from Settings → Notifications
• Redacted API responses and logs for destination URLs and request headers

Configure a destination#

1. Open Settings → Notifications.
2. Select Add destination.
3. Give the destination a recognizable name.
4. Choose Apprise URL or Generic JSON webhook.
5. Enter the destination URL.
6. Select the minimum severity, cooldown, event types, and optional service filters.
7. Select Save & test.
8. Enable outbound notifications after the test succeeds.

An empty event list matches every event. The service-filter dropdown is populated only from services currently enabled in DUMB and supports selecting more than one service. Disabled template services are not offered, and names that are not currently enabled are removed from the editable filter instead of being retained as hidden routing values. If enabled-service discovery is temporarily unavailable, destination saving and testing are paused until Settings is refreshed. Leaving every service unchecked matches all events, including events for any enabled service; selected entries use the exact process names shown by DUMB.

Save & test saves the destination and then bypasses the global switch, destination switch, severity/event/service filters, and cooldown for that one test. This is why a disabled destination can still be tested safely before normal delivery is enabled.

Apprise destinations#

DUMB uses the embedded Apprise Python library. It normally connects directly from the DUMB container to the provider named in the notification URL. Messages are not relayed through appriseit.com, and you do not need an Apprise account, hosted relay, separate Apprise API container, or sidecar.

Examples of URL families include:

• discord://...
• ntfy://...
• tgram://...
• mailto://...
• gotify://...
• slack://...

Use the official Apprise URL Builder or notification service documentation to construct the URL for a provider. DUMB never displays a saved URL after it has been stored. Leave the field blank to preserve the existing secret or enter a new URL to replace it.

Apprise's provider cache is kept in /config/notifications/apprise.

Generic webhook payload#

Generic webhooks receive an HTTP POST with JSON shaped like:

{
  "source": "DUMB",
  "event_id": "generated-event-id",
  "event_type": "service.auto_restart.failed",
  "severity": "critical",
  "title": "Auto-restart failed for Sonarr",
  "body": "Redacted failure summary",
  "service_name": "Sonarr",
  "timestamp": 1784300000.0
}

Optional request headers can be entered as a JSON object. Leave the headers field blank after saving to preserve existing secret headers.

TLS certificate verification is enabled by default. Disable it only for a deliberately trusted private endpoint using a self-signed certificate.

Event sources#

Service and startup events#

Update events#

• Update available when a service first enters the available state or the available version changes; unchanged scheduled checks do not resend it
• Update succeeded
• Update failed

Symlink operations#

• Repair, backup, or restore job succeeded
• Repair, backup, or restore job failed

Persistent conditions#

• CPU pressure
• Memory pressure
• Disk-capacity pressure
• Inode pressure
• Database pressure
• Database-health probe failure
• Recovery after the condition clears

Persistent conditions must remain active for duration_sec before DUMB sends them. This prevents a short spike from producing a notification.

Database events require Database Health collection to be enabled for the relevant service. Notification monitoring does not silently enable Database Health.

Severity and routing#

Severities are ordered as:

1. info
2. success
3. warning
4. critical

A destination receives events at or above its selected minimum. Recovery messages are controlled separately by Recovery messages, so a success recovery can still follow a warning or critical condition.

The routing order is:

1. Destination enabled state
2. Minimum severity
3. Event selection
4. Exact service-name filter
5. Recovery preference and cooldown

Automatic restart succeeded, Update succeeded, and Symlink job succeeded are normal Success events and are filtered by a Warning minimum. A recovery event is different: it represents a resource or Database Health threshold returning to normal, bypasses the minimum-severity check, and requires Recovery messages to be enabled.

Manual destination tests bypass normal routing plus the global and destination enable switches. This allows configuration testing before outbound notifications are enabled. A normal manual message bypasses the global switch and routing filters but still skips disabled destinations. If a destination is disabled after an automatic event has already been queued, DUMB keeps that record queued without consuming a retry attempt and resumes delivery only after the destination is enabled again.

Cooldowns, retries, and history#

Cooldowns are evaluated independently for each destination, event type, and service. Repeated matching events during the cooldown are recorded as suppressed but are not delivered.

Failed delivery uses exponential backoff starting at retry_base_sec. A delivery becomes failed after max_attempts.

Delivery history statuses are:

History is stored in /config/notifications/notifications.sqlite. Completed records older than history_retention_days are removed automatically. Clearing history from the UI does not delete queued or retrying deliveries.

What it cannot guarantee#

• A provider accepting a message does not guarantee a phone, email client, or chat application displayed it.
• DUMB cannot recover provider-side messages deleted or rejected after a successful API response.
• Notifications cannot be sent while the container, host, network, DNS, or destination provider is unavailable. Queued/retrying records survive a normal container recreation when /config is persistent.
• Resource thresholds are diagnostic signals, not proof that a service is failing.
• Database pressure does not predict the performance improvement from changing database providers.

Compatibility#

The frontend checks the backend notifications capability. When connected to an older DUMB backend, the Notifications section is hidden and other Settings functions continue to work.

Troubleshooting#

A test fails#

1. Open Delivery history and inspect the redacted error.
2. Confirm the URL syntax using the provider's Apprise documentation.
3. Confirm the DUMB container can resolve and reach the destination.
4. Verify certificates and system time for HTTPS endpoints.
5. For generic webhooks, confirm the endpoint accepts POST JSON.

Health events do not arrive#

1. Confirm outbound notifications are enabled globally.
2. Confirm the destination is enabled.
3. Check minimum severity, event selections, and exact service filters.
4. Check whether the event was recorded as suppressed by a cooldown.
5. For database events, confirm Database Health is enabled for that service.
6. For Service unhealthy and Auto-restart events, confirm Auto-restart is enabled globally and for the exact service.
7. To receive successful Auto-restart/update/symlink events, set minimum severity to Success or Info.

Related pages#

• Settings
• Metrics
• Auto-restart
• Auto-update
• Symlink Operations
• Notifications API