Notifications: email, webhook & Slack
Get told when something crosses a threshold, on the channel your team actually watches: email, a webhook, or Slack.
Add a channel
Go to Notifications in the sidebar (owner or admin only) and add a channel:
| Type | You provide |
|---|---|
| One or more recipient addresses | |
| Webhook | A URL, and optionally a signing secret |
| Slack | A Slack Incoming Webhook URL |
Set the threshold per channel — alert on critical only, or on warning and above. Use the Test button to send a sample alert immediately and confirm the wiring.
Choose the alert types
A threshold alone is blunt: critical only still mixes failed services, expiring certificates and attacks in one inbox. Each channel also picks which kinds of alert it wants — say, Active Defense to the on-call Slack and capacity to the team’s email:
| Alert type | Covers |
|---|---|
| Capacity | disk and memory pressure, a disk filling up, right-sizing |
| Availability | failed services, agents that stopped reporting, the post-mortem of every outage |
| Security updates & restarts | pending security packages, kernel update installed, restart required |
| Vulnerabilities | CVEs matched to the installed packages |
| TLS certificates | renewal failing or overdue, or expired |
| Exposure | services open to the internet, unprotected SSH, sites without HTTPS, secrets served, phpMyAdmin open |
| Attacks | security incidents rebuilt from web and SSH logs |
| Active Defense | the warden down, frozen or misconfigured, a rule demoted, a heavy address spared |
| Hardening advice | PHP-FPM vs database sizing, slow query log, real client IPs behind a proxy |
| End of life | an OS or key package past or nearing end of support |
| Everything else | any other type, including ones added in a later release |
A new channel, and every channel that existed before this choice did, gets all types. Ticking every box keeps meaning everything, including types added later. Change it with Edit on the channel’s row; the list shows each channel’s choice.
When alerts fire
A channel is notified when an Action becomes active and reaches its severity threshold — and only once per situation:
- it is told again if the Action escalates from warning to critical;
- and again if the problem comes back after being resolved, at least a day after the last alert — an Action that flaps (a timer failing twice a day) is one situation, not a new one each time;
- never because a number in it moved. A server going from 175 to 176 vulnerabilities is the same situation, already known.
If you snooze or acknowledge an Action, it won’t re-alert. No alert storms.
What is critical
Critical means it needs someone now. It is what a critical only channel — your on-call inbox — receives, so it is kept for:
| Critical | Why it cannot wait |
|---|---|
| A host that answers nothing | the agent is silent and the host does not answer from outside |
| A service that failed | something the host was running is down (a failed certbot renewal is a warning instead — see below) |
| A secret file served to the internet | a .env, a backup or a key is public right now |
| An attack hurting visitors | an ongoing incident sending errors to real visitors (once over, it becomes a warning: a report to read) |
| A disk about to fill | 95 % used, or full within 3 days at the current rate |
| A certificate expiring today, or expired | visitors see a browser warning |
| Active Defense frozen | blocking stopped after hitting its cap |
One warning reaches every channel subscribed to Availability, whatever its threshold: the post-mortem of an outage. A server that was cut off for three minutes and came back needs nobody now — but a critical only inbox is exactly the one that should hear about it.
Everything else is work to schedule and is a warning: vulnerabilities, a certificate renewal that fails, pending security updates, a kernel to reboot into, end of life, a service or phpMyAdmin exposed to the internet, hardening advice. They are on the dashboard, and on any channel set to warning and above.
When an agent goes quiet
An agent that stops reporting does not prove the host is down. It is equally consistent with a crashed agent, an egress firewall, or a planned reboot — so Demerzel does not guess. Once the silence passes your threshold it goes and dials the host from its own side, on the ports the agent last reported as listening (falling back to 443, 80 and 22), and alerts you with what it found:
| What we found | Severity | What it means |
|---|---|---|
| The host answers | Warning | The machine is up; the agent is what stopped. Restart it. |
| Nothing answers | Critical | The host or its network is down. |
| Nothing to dial | Warning | No routable address or public port is known — we say so rather than pick a side. |
The dials behind the verdict are shown on the server page, so the conclusion is always traceable to the connections behind it; they are kept for 30 days. A refused connection counts as answering: a TCP reset proves something is alive on the other end.
Choosing the delay
Set Alert after on the Notifications page. Left empty, it adapts per host: five missed reports based on the interval each agent reports for itself, never under 10 minutes — so a fleet reporting every 5 minutes is not judged by the same clock as one reporting every minute.
A host that is legitimately intermittent — a laptop, a VM suspended nightly — can be given its own delay or muted entirely from its server page. Muting one host is always better than raising the delay for the whole fleet, which is how a team learns to ignore the alert that mattered.
Webhook payloads
Webhooks receive a JSON body describing the alert (severity, title, detail, host, a link back to Demerzel). If you set a signing secret, each request carries an X-Demerzel-Signature: sha256=… header so your receiver can verify authenticity.
History
Every alert Demerzel has queued, sent or failed to send is kept under Notifications → View delivery history, with status and any delivery error — even after a channel is removed.