Notifications
DeepFilter continuously monitors, in the background, many of the components that keep email flowing: the validity of the secure connection (SSL) certificate, license verification, disk usage, the state of critical services and how full the cache memory is. When one of these checks fails, email flow most often breaks silently — a certificate expires, a service stops or a disk fills up, but from the outside everything looks like it is working and nobody notices.
The Notifications screen closes that gap: you define who receives an alert email and for which events. Instead of watching the server constantly, you configure the settings once and only hear about it when a real situation that needs intervention arises.
Settings
Admin Alert Emails
What it does: Holds the recipient email address(es) that critical system alerts are sent to. You can enter more than one address separated by commas (default: empty).
Why it exists: It defines a separate recipient list so alerts reach the right person or team responsible for the server; it lets you set a target independent of the list the daily reports go to.
If you change the value: If you fill the field in, alerts go only to the addresses here. If you leave it empty, alert recipients are taken from the Inbound Email → Digest → Admin/Test Recipients list; if that list is empty too, no alert is sent at all and the event is only written to the system log.
When you save, the addresses go through a basic format check (each part must
contain @, and it must not start or end with @); an invalid address causes the
save to be rejected. This check does not verify that the address actually
exists or can receive mail.
When you fill this field in, alerts go only to the list here and the fallback to the daily report (Digest) recipient list is disabled. Use a team or a distribution (SOC) address rather than a single personal address; otherwise critical alerts can slip by unnoticed while that person is on leave or without access.
Notification Types
What it does: Each row in the list is a monitored event type; while the switch to its right is on, an alert email is sent to the defined addresses when that event occurs, and while it is off no alert is produced for that event (default: all on).
Why it exists: Not every environment cares about every event to the same degree. Being able to turn types on and off individually lets you cut unnecessary alert noise and receive only the events you care about.
If you change the value: If you turn a type off, the event still happens — the event itself is not prevented, you are simply not told about it. Notification types added in new versions arrive on by default.
Every alert email is sent with the same corporate template as the daily Digest
reports; its urgency can be told from the prefix in the subject line:
[DeepFilter] (informational), [DeepFilter Uyarı] (warning) and
[DeepFilter KRİTİK] (critical). You can define prioritization rules in your inbox
based on these prefixes.
The monitored event types:
- SSL Certificate Expired — Sends a critical alert after the server's secure connection (SSL) certificate has expired. The certificate is checked every day, but the alert is triggered only once the date has passed; it does not produce an advance "expiring soon" warning. A single alert is sent for the same expiry date.
- SSL Renewal Failed — Sends a critical alert when an error occurs during the automatic renewal of the certificate. It is not a scheduled check; it is triggered immediately after each failed renewal attempt.
- License Heartbeat Failed — DeepFilter connects to the license center at regular intervals to verify the license. If the connection cannot be established, a 14 calendar-day countdown starts from the moment verification was interrupted; during that period no protection is reduced and the system keeps running at full capacity. The administrator receives notification emails as the number of days remaining falls before the period runs out, and sees a warning banner at the top of the panel that cannot be dismissed. When the connection is re-established, the countdown resets on its own. For details see the License page.
- License Blocked — When the license center reports copy (clone) usage, an identity mismatch or a blocking decision, the system is stopped in a protected manner and a critical alert is sent.
- Disk Full — Triggered when one of the monitored critical disk partitions reaches 85% (warning) or 95% (critical) usage. Partitions are checked hourly; if several partitions are full at the same time, the alerts are combined into a single email at the highest severity.
- Service Down — Critical DeepFilter services are checked every five minutes. If a service has stopped, the system first tries to restart it automatically (at most two attempts for the same event); if the service still does not come up, it sends a critical "down" alert. The same type also sends an informational message when the service comes back up, and a warning email when the state of a service cannot be read.
- Cache Memory Filling Up — Triggered when the cache memory that holds counters, queues and temporary data reaches 80% (warning) or 90% (critical) usage. The memory is checked hourly.
Take the Cache Memory Filling Up alert seriously: when this memory fills up, functions such as background tasks, quarantine, spam learning and Temporary Rejection can stop silently while the services keep looking like they are "running" from the outside. Receiving the alert early gives you the chance to intervene before the problem grows.
Configuring Notification Settings
Prerequisites
- Alert emails use the same delivery infrastructure as the Digest reports, so outbound email delivery must be working. Otherwise an alert can be produced but not delivered.
Steps
- Open Management → Notifications.
- In the Admin Alert Emails field, write the address(es) the alerts should go to; separate multiple addresses with commas.
- In the Notification Types list, keep the switch on for the events you want to receive and off for the ones you are not interested in.
- When you make a change, click the Save button that appears in the bottom corner. This button does not appear until a change is made; settings are not saved on their own.
Verification — how to know it worked
- After you save, the Save button disappears; this shows that no pending change is left and that the settings have been applied. There is no button on this screen that sends a test email; you see that the settings work from the alert you receive when a real event (a service stopping, for example) is triggered.
Things to Watch
If you turn off every notification type, you receive no alert at all in critical situations such as a certificate expiring, a service stopping or a disk filling up. At the very least keep the SSL Certificate Expired, Service Down and Disk Full types on.
Troubleshooting
No alert emails arrive at all. Check the recipient first: if both the Admin Alert Emails field and the fallback Digest recipient list are empty, no alert is sent (the event is only written to the log). Then confirm that outbound email delivery is working and that the relevant notification type is on.
The SSL certificate is nearing expiry but no alert arrived. This is by design: the system alerts only when the date has passed or when automatic renewal fails; it does not produce an "expiring soon" warning. To renew the certificate before it expires, make sure automatic renewal is working.
The disk filled up but no alert appeared. Only specific disk partitions that are critical to the system's operation are monitored. If the partition that filled up is not one of them, no alert is produced.
The cache memory looks full but no alert arrives. If no upper limit is defined for the cache memory (an unlimited configuration), the usage check is skipped entirely and no alert is produced.
The same problem is ongoing but the alert arrived only once. Most types suppress repeated emails for the same situation within a certain time window, so a single ongoing problem does not fill your inbox. When the problem is resolved and then reappears, the alert is sent again.