Alarm

Overview

Kubernetes Monitoring

Monitor pod and node health statuses

Elasticsearch Monitoring

Track cluster health and resource usage

Resource Monitoring

Monitor CPU and disk usage rates

Certificate Management

Track SSL and JWK certificate durations

Log Monitoring

Monitor application log counts

Automatic Notifications

Receive instant notifications when threshold values are exceeded

What is Alarm?

Basic Concept

Alarm is a monitoring system that continuously checks specific conditions in your system and sends notifications when these conditions are met.

When to Use?

System Health Monitoring

Monitoring pod, node, and Elasticsearch health statuses

Resource Usage Monitoring

Tracking CPU and disk usage rates

Certificate Management

Tracking SSL and JWK certificate durations

Log Management

Monitoring application log counts

Proactive Warning

Receiving warnings before problems occur

Automatic Notification

Receiving automatic notifications in critical situations

How Does It Work?

Configuration

Trigger type, threshold value, scheduling, and notifications are determined

Scheduling

Automatic checks are performed at specified times (e.g., every hour)

Check

A specific metric or status is checked according to the trigger type

Threshold Check

If there is a threshold value, it is checked whether the checked value exceeded the threshold value

Notification

When the threshold is exceeded or status changes, configured notifications are triggered

Recording

All checks are recorded in history

Quick Start

Creating Your First Alarm

Access from Menu

Click Main Menu → Monitoring → Alarm

Create New Alarm

Click the "Create New" button

Fill in Basic Information

• Name: A name for the alarm (e.g., "Elasticsearch CPU Monitoring")
• Description: Optional description

Select Trigger Type

Select the trigger type (e.g., Elasticsearch CPU Percentage)

Enter Threshold Value

Enter the threshold value (e.g., 80)

Set Scheduling

Determine the check frequency (e.g., Every hour)

Save

Click the "Save" button

Creating New Alarm

Step 1: Basic Information

Name - Required

Enter a unique name for the alarm. This name:

• Must be unique within the project
• Cannot start with a space
• The system automatically checks the availability of the name

Good Name Examples:

• Elasticsearch CPU Monitoring
• Kubernetes Pod Health Status
• SSL Certificate Duration Tracking
• Application Log Count Monitoring

Description - Optional

You can enter descriptive information about the alarm:

• Maximum 1000 characters
• Used to explain the purpose and scope of the alarm
• Displayed on the list page

Example Descriptions:

• Created to monitor CPU usage of Elasticsearch cluster
• Used to track health status of Kubernetes pods
• Configured to warn before SSL certificates expire

Status - Default: Active

Determines the active/passive status of the alarm:

• Active: Alarm runs, scheduled checks are performed
• Passive: Alarm is stopped, no checks are performed (historical data is preserved)

Step 2: Trigger Type and Threshold Value

Trigger Types

Determines when the alarm will be triggered. The trigger type picker is searchable and groups the types into three categories; each type is shown in lists with a category badge:

• Infrastructure: Kubernetes pod/node health, K8S Node CPU, Elasticsearch health/CPU/disk
• Platform: API Traffic (logs in database), SSL/JWK remaining duration, application log count
• AI: AI Gateway metrics (token usage, daily cost, guardrail/PII count, provider failover, quota, catalog drift, shadow AI)

Infrastructure

• Pod / Node Health Status
• K8S Node CPU Percentage
• Elasticsearch Health / CPU / Disk Percentage

Platform

• API Traffic (Logs in Database)
• SSL / JWK Certificate Remaining Duration
• Application Log Count

AI

• AI Token Usage Percentage / Daily Cost
• Guardrail / PII Detection Count
• Provider Failover, Quota, Catalog Drift, Shadow AI

Kubernetes Trigger Types

Pod Health Status: Checks the health status of Kubernetes pods. Alarm is triggered when any pod becomes unhealthy. Does not require threshold value.

Node Health Status: Checks the health status of Kubernetes nodes. Alarm is triggered when any node becomes unhealthy. Does not require threshold value.

K8S Node CPU Percentage: Checks the CPU usage percentage of Kubernetes nodes. Alarm is triggered when CPU usage percentage exceeds the threshold value. Requires threshold value (e.g., 80 = 80%).

Elasticsearch Trigger Types

Elasticsearch Health Status: Checks the health status of Elasticsearch cluster. Alarm is triggered when cluster becomes unhealthy. Does not require threshold value. Requires connection definition.

Elasticsearch CPU Percentage: Checks the CPU usage percentage of Elasticsearch cluster. Alarm is triggered when CPU usage percentage exceeds the threshold value. Requires threshold value (e.g., 80 = 80%). Requires connection definition.

Elasticsearch Disk Percentage: Checks the disk usage percentage of Elasticsearch cluster. Alarm is triggered when disk usage percentage exceeds the threshold value. Requires threshold value (e.g., 90 = 90%). Requires connection definition.

Elasticsearch Logs in Database: Checks whether Elasticsearch logs are in the database. Alarm is triggered when logs are in the database. Does not require threshold value.

Certificate Trigger Types

SSL Certificate Remaining Duration: Checks the remaining duration of SSL certificates. Alarm is triggered when remaining duration is less than the threshold value. Requires threshold value (e.g., 30 = 30 days).

JWK Certificate Remaining Duration: Checks the remaining duration of JWK certificates. Alarm is triggered when remaining duration is less than the threshold value. Requires threshold value (e.g., 30 = 30 days).

Application Log Trigger Types

Application Log Count: Checks the count of a specific application log type. Alarm is triggered when log count exceeds the threshold value. Requires threshold value (e.g., 10000 = 10,000 records). Log type must be selected.

Supported Log Types:

• Manager Logs
• Gateway Logs
• Cache Logs
• Integration Logs
• Portal Logs
• Audit Logs Manager
• Audit Logs ACL
• And more...

Threshold Value

Threshold value determines when the alarm will be triggered. Different units are used according to the trigger type:

Trigger Type	Unit	Example Value	Description
K8S Node CPU Percentage	%	80	When CPU usage exceeds 80%
Elasticsearch CPU Percentage	%	80	When CPU usage exceeds 80%
Elasticsearch Disk Percentage	%	90	When disk usage exceeds 90%
SSL Certificate Remaining Duration	Days	30	When remaining duration is less than 30 days
JWK Certificate Remaining Duration	Days	30	When remaining duration is less than 30 days
Application Log Count	Records	10000	When log count exceeds 10,000

Tip

Threshold Value Recommendations:

• CPU Monitoring: Between 70-80%
• Disk Monitoring: Between 80-90%
• Certificate Tracking: Between 30-60 days
• Log Count: According to system capacity

Connection Definition

Some trigger types require Elasticsearch connection:

Trigger Types Requiring Connection:

• Elasticsearch Health Status
• Elasticsearch CPU Percentage
• Elasticsearch Disk Percentage

Trigger Types Not Requiring Connection:

• Kubernetes trigger types
• Certificate trigger types
• Application log trigger types

Note

Elasticsearch connection is selected from connections created on the Connection Management page. Connection must be active and accessible.

Step 3: Scheduling Settings

Determine how frequently the alarm will be checked. Scheduling is done using Cron Expression.

Common Scheduling Examples

Description	Cron Expression	Use Case
Every hour	0 0 * ? * *	For general monitoring (most common)
Every 30 minutes	0 */30 * ? * *	For critical systems
Every 15 minutes	0 */15 * ? * *	For very critical systems
Every day at 09:00	0 0 9 * ? *	For daily reporting
Every 5 minutes	0 */5 * ? * *	For situations requiring very frequent checks

Tip

Recommendations:

• General Monitoring: Every hour
• Critical Systems: Every 15-30 minutes
• Certificate Tracking: Every day at 09:00
• Resource Monitoring: Every 30 minutes

Step 4: Notification Recipients

Configure recipients who will receive notifications when the alarm is triggered:

Adding Notifications

Add to Actions Table

Click the "Add" button in the Actions table

Select Notification Type

Supported notification types:

• Email: Sends email notification
• Webhook: Sends HTTP POST request
• Slack: Sends message to Slack channel
• SMS: Sends SMS notification
• System Notification: Sends in-system notification
• And more...

Complete Notification Configuration

Fill in the required information according to the notification type

Note

For detailed information about actions, see the Connectors page.

Notification Management

Notification Table Columns:

• Name: Notification name
• Type: Notification type (Email, Webhook, Slack, etc.)
• Status: Active/Passive status
• Description: Notification description

Notification Operations:

• Edit: Select "Edit" from the menu to update notification information
• Delete: Select "Delete" from the menu to remove the notification
• Active/Passive: You can activate/deactivate the notification with toggle

Step 5: Saving

After filling in all information:

1. Make sure form validations pass:

   • ✅ Name entered and available
   • ✅ Trigger type selected
   • ✅ Threshold value entered (if required)
   • ✅ Connection definition selected (if required)
   • ✅ Scheduling settings configured

2. Click the "Save" button

3. After the alarm is saved, you will be automatically redirected to the listing page

View and Results

Clicking the alarm name — or selecting "View" from the operations menu (⋮) — opens the alarm's single-page View screen. It shows both the latest evaluation results and the configuration in one place; there is no separate history page.

Header and Metric Cards

The top bar has Refresh, Activate/Deactivate, Back and Edit buttons. Below it are 5 summary metric cards:

• Current value: The value from the last evaluation (coloured by state)
• Threshold: The alarm's threshold value
• Last fired: Time of the most recent threshold breach
• Fires (24h): Number of times fired in the last 24 hours
• Actions: Number of attached notification channels

Tabs

Matched records

Every object evaluated on the last run (each Elasticsearch node, certificate, pod…), worst first. Each row shows the object name, value and a state badge:

• 🔴 BREACHED: Threshold exceeded
• 🟠 WARNING: Close to the threshold
• 🟢 NORMAL: Within safe limits

An "n of m breached" badge, an "Only breached" filter and pagination are provided.

Trigger history

The result of each evaluation — paginated table:

• Evaluated at: Evaluation date/time
• Value: The measured value
• Result: 🟢 Threshold Not Exceeded · 🔴 Threshold Exceeded · 🟠 Error Occurred
• Summary: Check summary

Configuration

A read-only definition of the alarm:

• Alert definition: Name, description and Status: Enabled / Disabled badge
• Trigger: Trigger type + category badge, threshold, connection, log type, AI scope
• Schedule: Cron expression
• Actions: Notification channels (type, name, status)

Live Check Panel

The Live check panel on the right of the View screen runs the alarm's condition right now — without saving — and shows whether the alarm would fire:

• Evaluate now: Evaluates the condition immediately. This evaluation writes a Trigger history record and updates the current value in the list view; it does NOT fire notifications/recipients. The last evaluation time is shown below the button.
• Worst object: The value of the currently worst object with a threshold-marked bar.
• Objects evaluated: The evaluated objects and an "n of m breached" badge.
• Last 12 evaluations: A line chart of recent evaluations with a red dashed threshold line.
• Result box: "Condition met — the alert would fire" (red), "Condition not met" (green), or an evaluation error (amber).

Note

When the page opens the condition is evaluated automatically in read-only mode (no history is written); only the Evaluate now button writes a history record.

Alarm Management

List Page Features

On the alarm list page, you can view and manage all your alarms.

Search and Filtering

• Name search: Filters by name (contains match)
• Description search: A separate search box that filters by description (contains match)
• Project Filter: Filter alarms by project (the admin list spans all projects)
• Status segment: All / Firing / Normal / Disabled
• Source segment: All sources / Infrastructure / Platform / AI — fed by the trigger type category

Table Columns

• Alert: Status dot + alarm name (clickable, goes to the View page) + description + breach summary ("N records breached · closest …")
• Trigger type: Trigger type + category badge (Infrastructure/Platform/AI)
• Condition: The condition (e.g. ≥ 85 %, is not healthy, stops arriving)
• Current value: The value from the last evaluation (coloured) + threshold reference + bar
• Every: Check interval (e.g. 5m, 24h)
• Project: The alarm's project
• Actions: Notification channel chips
• ⋮: Operations menu

Operations Menu

For each alarm, click the menu button (⋮) to perform the following operations:

1. View: Open the alarm's View page (metrics + Live check + history)
2. Edit: Update alarm settings
3. Activate / Deactivate: Enable or disable the alarm
4. Duplicate: Create a copy of the alarm
5. Delete: Delete the alarm

Changing Status (Activate/Deactivate)

To change the alarm's enabled/disabled status, select Activate or Deactivate from the operations menu (⋮). The same action is also available in the top bar of the View screen. Only the enabled flag changes; notification recipients and schedule are preserved. Disabled alarms do not run, but their historical data is preserved.

Best Practices

Naming Conventions

• Use descriptive names: Elasticsearch CPU Monitoring
• Add environment/project prefix: Production - SSL Certificate Tracking
• Specify trigger type: K8S Node CPU Monitoring

Threshold Value Strategy

• CPU Monitoring: Between 70-80%
• Disk Monitoring: Between 80-90%
• Certificate Tracking: Between 30-60 days
• Log Count: According to system capacity

Scheduling Strategy

• Critical Systems: Every 15-30 minutes
• General Monitoring: Every hour
• Certificate Tracking: Every day at 09:00
• Resource Monitoring: Every 30 minutes

Notification Management

• Critical Alarms: Email + SMS notification
• General Alarms: Email notification is sufficient
• Webhook: Send notifications to your integration systems
• Notification Spam: Avoid notification spam with appropriate scheduling

Frequently Asked Questions

How Often Does Alarm Run?

The frequency of alarm execution depends on the Scheduling (Cron Expression) settings you determined when creating it. For example:

• 0 0 * ? * * → Every hour
• 0 */30 * ? * * → Every 30 minutes
• 0 0 9 * ? * → Every day at 09:00

What Happens When Alarm is Deactivated?

When alarm is deactivated:

• No new checks are performed
• Existing scheduled jobs are cancelled
• History records are preserved and can be viewed
• Alarm continues normal operation when reactivated

How is Threshold Value Determined?

Threshold value should be determined according to your system's normal operating conditions:

• CPU Monitoring: 20-30% above normal CPU usage
• Disk Monitoring: 80-90% of disk capacity
• Certificate Tracking: Before certificate renewal time (e.g., 30 days)
• Log Count: According to system capacity

Can I Add Multiple Notifications?

Yes, you can add multiple notifications. Each notification:

• Can be a different type (Email, SMS, Webhook, etc.)
• Can be sent to different recipients
• Can be independently activated/deactivated

How Long Are History Records Kept?

History records are kept until manually deleted. To clean old records:

• You can use the "Delete All" button on the history page
• Or you can clean records regularly

What Happens When Alarm is Deleted?

When alarm is deleted:

• Alarm definition is deleted from database
• All history records are deleted
• Scheduled jobs are cancelled
• Historical data is permanently lost

Warning

Warning: Deletion cannot be undone!

Troubleshooting

Alarm Not Working

Possible Causes:

1. Alarm may be in disabled status → Select Activate from the operations menu (verify from the Configuration tab of the View screen)
2. Scheduling settings may be wrong → Check cron expression
3. Elasticsearch connection may not exist or be inaccessible → Check connection settings
4. Threshold value may be incorrectly configured → Check threshold value

Solution:

• Activate alarm status
• Check scheduling settings
• Check Elasticsearch connection
• Check threshold value

All Results Are in 'Error Occurred' Status

Possible Causes:

1. Elasticsearch connection does not exist or is inaccessible
2. Kubernetes cluster is inaccessible
3. System resources are insufficient
4. Configuration error

Solution:

• Check Elasticsearch connection
• Check Kubernetes cluster connection
• Check system resources
• Check alarm configuration

Too Many Notifications Coming

Possible Causes:

1. Threshold value is too low
2. Scheduling is too frequent
3. Multiple notifications are active

Solution:

• Increase threshold value
• Reduce scheduling frequency
• Deactivate unnecessary notifications

Notifications Not Coming

Possible Causes:

1. Notification is in passive status
2. Notification configuration is incorrect
3. Email/SMS service is not working

Solution:

• Activate notification status
• Check notification configuration
• Check Email/SMS service settings

Additional Resources

Connectors

Notification and action configuration

Scheduled Jobs

Cron expression and scheduling settings

Connection Management

Elasticsearch connection management

Kubernetes Monitoring

Kubernetes pod and node monitoring