Notifications
Middlewarr sends notifications through Shoutrrr destinations. Each destination has a name, a service URL, an active state, and a selection of events.
Add a destination
Section titled “Add a destination”- Open Settings → Notifications → New provider.
- Give it a recognizable name.
- Enter the Shoutrrr URL for your notification service.
- Select the events you want and leave the destination active.
- Choose Send test in the form to confirm delivery, then choose Create. To test an existing provider, open its edit form.
Use the URL format for your provider, not an ordinary browser link to a channel. The application validates whether its bundled Shoutrrr build recognizes the URL; the test then checks whether delivery succeeds.
Treat the destination URL as a secret when it contains a webhook token, password, or other credential. Keep it out of screenshots and public issue reports.
Choose events
Section titled “Choose events”| Category | Events |
|---|---|
| Access | Unknown app slug, inactive app, missing key, invalid key, endpoint not enabled |
| Services | Upstream service unreachable and recovered |
| Configuration | App, service, and proxy changes |
| Templates | Repository changes, templates synced, and automatic preservation of removed permissions |
An active destination with no selected events receives no automatic event notifications. Choose a small set that you can act on, then add more if needed.
Access alerts are sent when a new unresolved warning is recorded. Repeated matching failures increase its count without sending a message for every request. A recurrence after dismissal can generate a new alert.
Understand service alerts
Section titled “Understand service alerts”Service-unreachable and recovery alerts are observed from proxied requests. Middlewarr records a connection failure when it cannot reach the upstream service, then recovery when a later request receives a response.
These alerts are not a scheduled uptime monitor. A quiet service may fail without an immediate alert. An HTTP error returned by a reachable service is also different from a network connection failure.
The service status displayed in the dashboard can use health checks; that does not make notification delivery a periodic monitoring service.
If delivery fails
Section titled “If delivery fails”Check the test result, destination URL, event selection, and active state. Then look at the container logs for the destination name and delivery error.
Notifications are dispatched in the background so a delivery failure does not block the operation being reported. Do not use them as the sole record of a configuration change or access attempt; inspect logs and warnings too.