Repository navigation
Notifications
Since 1.7.0.
Fleet and security events delivered to Slack, Telegram, Discord, ntfy, email and the rest — anything Apprise supports — from Settings → Notifications.
Run an Apprise API instance (the caronc/apprise Docker image is one
container), point Apprise API endpoint at it, and choose a delivery mode:
- Saved configuration key — destinations live in Apprise, CortenDesk sends to a named config.
- Apprise URLs — paste destination URLs straight into CortenDesk.
Either way the endpoint and credentials are encrypted at rest and never shown again after saving. Send test delivers a real message.
Per-event switches: device pending approval, device offline, device recovered, failed console sign-in, security alarm, repeated remote connection failure, backup completed, backup or off-site copy failed. Device events can be scoped to chosen groups or devices.
The cooldown (default 15 minutes) is per event and subject — a flapping device cannot flood a channel, and one noisy device cannot silence another's alarm.
Each message carries an Apprise type, and Slack, Discord and similar colour it by that: device recovered is success, device offline is info, pending approval and failed console sign-in are warning, security alarm and repeated connection failure are failure. Backup completed is success, a failed backup or off-site copy is failure (since 1.14.0). Since 1.9.1; before that every message was warning.
Since 1.8.1.
Offline alert grace (minutes) holds back the device offline alert. Default 0, up to 1440. A device counts as offline once the Online window (60 seconds by default, Settings → Server) passes after its last heartbeat, and the grace starts then. A device that comes back within the grace sends nothing. Use it for machines that reboot or drop off the network for a few minutes.
The scheduler checks presence once a minute, so an alert can arrive up to a minute after the grace ends.
A recovery alert follows only an offline alert that was delivered. That record is kept in the database, so a restart in between does not lose the recovery.
Since 1.8.1. Administrators only.
Presence alert maintenance, below the notification settings, mutes device offline and device recovered alerts for one device or one device group. Use it for planned work.
Choose Device or Device group under Apply to, pick the target, set Minutes (15 to 10080, default 60) and click Snooze alerts. Snoozing a target again replaces its end time. Active snoozes are listed with their end time, and End now removes one. Both are recorded in the console audit log.
- A group snooze covers the devices in that group at the time of the check.
- A device that goes offline during a snooze sends no alert. If it is still offline when the snooze ends, the alert goes out then.
- A device that comes back during a snooze sends no recovery alert, even if its offline alert went out before the snooze started.
- Pending approval, failed sign-in, security alarm and connection failure alerts are not affected.
Since 1.11.0.
A send that looks like a temporary failure is tried again: a timeout, a connection error, or HTTP 429, 424 or 5xx from Apprise. The Apprise API answers 424 when it reached Apprise but a destination such as Slack failed. Other HTTP errors mean the request or the configuration is wrong and are not retried.
- Three attempts in all: the first send, another about a minute later, and a last one about five minutes after that. The scheduler runs them, so a manual install needs its cron entry.
- Nothing older than 30 minutes is retried.
- A retry is dropped when a newer event replaces it, and shows as superseded. An offline alert is never sent once the device is back.
- A retry is also dropped when its event has been switched off, or the device is snoozed under Presence alert maintenance.
- Send test is not retried.
Apprise answers only after it has posted to the destination, so a slow Slack or
mail hop makes Apprise slow. Sends the scheduler makes (offline and recovery
alerts found by the per-minute check, and every retry) wait up to 15 seconds.
Set CORTENDESK_NOTIFY_TIMEOUT (1 to 60 seconds) to change that. Sends made
while the console handles a request, such as a failed sign-in or a security
alarm, wait 3 seconds so a slow Apprise cannot hold up the web server.
Recent deliveries show under the settings, with transport URLs and credentials redacted. The device page lists the ones about that device. A delivery waiting for another attempt is marked retrying, with the attempt number and when the next one is due. History is pruned with the audit logs.
What this is not: invitations, password resets and sign-in codes stay on email — each is addressed to one person and has to reach only that person.