In a production environment, not every event carries the same weight. A backend in maintenance, all backends down, the cluster IP failing over to another node, a certificate expiring in 30 days, and a request rate breach all require different operational responses. When all of these collapse into the same generic email alert, teams quickly develop alert fatigue.
Classic approaches typically limit notifications to email and syslog. Yet operations teams want different events delivered on different channels: a critical failover via SMS, a routine warning in the UI, a security event via SNMP or Syslog, and an executive digest by email. Without channel separation, either everyone receives everything, or critical events get missed.
Quiet-hours management matters too. Waking the entire team at 03:00 for a low-severity alert is unnecessary, but a genuine outage or cluster IP change still needs to be visible. Quiet hours should mean handling the event at the right time on the right channel — not losing the event entirely.
Reporting pool down, backend down, cluster IP swap and zone closure with the same generic message makes root-cause analysis harder. The operator must first decode what the alarm means, then act. That delay has a direct impact on service quality — especially on high-traffic platforms.
TR7 Notification System disambiguates events through alarm lifecycle management, 30+ predefined status keys, multi-channel delivery, multi-language templates, quiet hours and per-pool threshold configuration — getting the right information to the right person, on the right channel, with the right context.
TR7 manages notifications not as one-shot messages but as alarm objects with a lifecycle and channel-specific actions.
Active alarms are keyed by alarmKey, updated through updateAlarm and closed with endAlarm. The same event is never re-created as a new alarm; its start, update and end are all tracked in one object.
Alarm and notification state can be propagated to other nodes in the cluster. Operations teams see critical conditions across the entire cluster, not only the events on the node they happen to be connected to.
Pool status is classified as UNKNOWN, OK, WARN, DISABLED, ERR or EVALUATING. This model avoids collapsing maintenance, warning, error and evaluation states into a single undifferentiated alarm text.
Cluster IP conditions are evaluated through separate signals: interface reachability, IP collision, IP transition and dual-node behavior. Failover events are delivered to the operations team with precise context.
Notification System provides alarm lifecycle management, per-pool thresholds, multi-channel delivery, multi-language templates, quiet hours, certificate warnings and archivable event history.
The updateAlarm, endAlarm and getAlarms flow tracks active alarms through their full lifecycle. When the same alarmKey recurs, the existing alarm is updated rather than duplicated as a new one. Fields such as staticPayload, ifAbsent and dontNotify give finer control over event behavior. The result is reduced alarm noise and a more meaningful event history.
Each pool can define thresholds for serviceStatus, poolStatus, bandwidth, request rate, current sessions and new connections. Within the same configuration, channel preferences for email, SMS, WhatsApp, BiP, SNMP and UI can be set independently. A critical service can use an aggressive alarm policy; a low-priority service can use a quieter one. Notification behavior is not applied uniformly across the platform.
TR7 supports email, SMS, WhatsApp, BiP, SNMP, Syslog and UI as delivery channels. Critical infrastructure events can reach network management systems via SMS or SNMP, executive summaries can go by email, and routine status can be shown in the UI. The same event can be sent to different channels at different priority levels. This flexibility reduces dependence on a separate external alert manager.
NotificationTranslator uses a dictionary-based translation engine to generate notification text in multiple languages. A Turkish-speaking operations team receives notifications in Turkish; an international team receives them in English. The same event can be delivered in different languages to different users. This reduces misinterpretation risk in multi-country operations.
More than 30 status keys are available: poolDisabled, allBeDown, noBeGiven, beDown, beStateUnknown, beMaint, poolDown, poolInterfaceAbsent, zoneClosed, clusterIpBoth, clusterIpPossibleCollide, clusterIpSwitched, clusterIpNone and others. These keys make alarm text far more descriptive. Operators receive not just a generic "service issue" message but the exact nature of the problem. Mean time to respond decreases.
Specific notifications can be suppressed via silentAtNight during overnight hours. This does not mean the event disappears — it can remain visible in the UI and be included in a morning digest. A separate channel policy for critical events ensures genuinely important alarms are still delivered. Alert fatigue is reduced without sacrificing operational visibility.
The notifyDaysBeforeCertificateExpiry field triggers an alert a configurable number of days before a certificate expires — for example, 30 days in advance via email or UI notification. Certificate renewals no longer wait until the last moment. Oversights that could cause TLS outages are caught early.
Contact group members are defined with email addresses, SMS numbers and user-type metadata. Notifications can be directed to individual users, team groups or user types. This model makes it straightforward to target on-call teams, SOC, SRE or management groups separately. Personnel changes can be managed without disrupting channel policies.
SMTP host, port, authentication, username, password, TLS security, certificate verification, sender name, sender address, cc, bcc, attachments and HTML message format are all configurable. The email connection timeout can be set to 10 seconds. This makes integration with the organization's existing mail relay or SMTP infrastructure straightforward. Email notifications can be aligned with brand and security policies.
Alarm and notification logs can be archived under separate names. Zip compression with a high compression level keeps historical events available for audit and review. Notification history becomes audit evidence for PCI, change management or post-incident analysis. External archiving processes can run alongside local visibility without conflict.
The NotificationType field classifies events as A (alarm), N (notification) or I (info). This distinction determines criticality and how the event is presented to the user. Not every informational message behaves as an alarm; not every alarm is lost as a routine notification. UI and external channel behavior is driven by this classification.
The BasicNotification pairId field links notifications that belong to the same event group. The opening, updating and closure of a single alarm can be tracked within one event family. This makes it easy to view the full event chain together in SIEM or audit tools. The complete event sequence — not just isolated messages — can be analyzed.
Notification System operates alongside pool status values, log names, compression settings, SMTP security and the cluster IP state machine.
Pool status is classified numerically: UNKNOWN=-1, OK=0, WARN=1, DISABLED=2, ERR=3 and EVALUATING=4. This numeric model provides a consistent basis for alarm evaluation and UI rendering. States are treated as actionable decision values, not merely text labels.
Alarm logs are stored under the name basic-alarms; notification logs under basic-notifications. This separation allows the event lifecycle and the notifications delivered to users to be reviewed independently. Operations and audit processes can consume each log type according to their own requirements.
Alarm and notification archives can be stored in zip format with a high compression level. This reduces long-term storage cost and makes historical notification records more accessible for audit purposes.
More than 30 predefined status keys are available under the `_lb.*` namespace. These keys describe pool, backend, interface, zone and cluster IP behaviors at a granular level. Notification text and decision logic are enriched through these keys.
Email delivery connection timeout can be configured to 10000 ms. TLS security and certificate verification behavior are user-controlled. This allows mail relay integration to be tuned to the organization's security requirements.
Cluster IP conditions are interpreted through a dedicated state machine. IP unreachability, interface state, possible collision and node transition are converted into combined cluster IP state values. Failover alarms are generated with more accurate context as a result.
When a low-severity backend-down event occurs at 02:00, silentAtNight can stop the email from being sent. The event stays active in the UI and can be included in the morning digest. Unnecessary overnight alerts are reduced without losing the event entirely.
Operations teams can set notifyDaysBeforeCertificateExpiry to 30 days. As the certificate deadline approaches, the system generates an email or UI notification. Last-minute renewal risks that could cause TLS outages are eliminated.
When the cluster IP transitions to another node, a clusterIpSwitched event is generated. This event can be delivered to the operations team via SMS, SNMP or UI. When a failover occurs, the team is informed at the moment it happens — not after.
When a request rate, bandwidth, session or new-connection threshold is exceeded, an SNMP notification can be generated. The network management system receives the event on its own alarm dashboard. Security and network operations teams see the same threshold in a shared monitoring stream.
Alarm and notification logs can be stored as compressed archives. During an audit, it is possible to show which event occurred, when it occurred, which channel was used and whether the alarm was closed. Notification history becomes operational evidence.
A team in one country can receive the same alarm as a Turkish-language email while the international operations team receives an English-language message. NotificationTranslator generates event text in the user's language. Misinterpretation risk in multi-country operations is reduced.
Alarm lifecycle, 30+ status keys, multi-channel delivery and quiet hours. Let us walk through a live setup in your own environment.