The Alarm Center is a centralized monitoring area designed to help you track critical security, infrastructure, and system events across the entire system from a single place.

This screen doesn’t only answer “what happened?” — it also provides a clear framework for “when should I be notified?”.

Through the Alert Center, you can:

• Monitor all alerts generated across the system in real time
• Define which conditions should trigger an alert
• Decide who should be notified and through which channels when an alert is triggered
• Analyze system behavior by reviewing historical alerts

The Alert Center consists of three main sections, each serving a different purpose: Alerts, Rules, and Insights.

Alerts

The Alerts screen is the primary monitoring area where all triggered alerts—generated as a result of your defined alert rules—are listed.

Alert Details

When you click Details for any alert in the Alerts table, you can examine why the alert was triggered, which conditions were met, and the system state at the time of triggering in detail.

1. General Information

   The top section of the details screen contains core information that defines the alert’s context:

   Field	Description
   Date	Date and time when the alert was triggered
   Alarm Rule	Name of the alert rule that generated the alert
   Type	Type of the alert rule (Custom, Inline, Legacy ZTNA)
   Severity	Severity level defined in the alert rule

2. Criteria Information

   This section clearly explains why the alert was generated.

   🔹 For Custom Alert Rules

   Since custom alert rules have their own criteria:

   • All criteria defined in the rule are listed in detail
   • Which criteria were matched is clearly shown
   • Threshold behavior (immediate / repeated / consistent) is indicated
   • Notification channels used are displayed

   🔹 For Inline Alert Rules

   The alert triggering logic is defined within the associated policy itself.

   Instead, the screen shows which policy or detector generated the alert and which notification channels were used.

Alert Rules

Alert rules are the core mechanism that defines how the Alert Center operates, which situations are considered, and when alerts are generated.

With alert rules, the system:

• Avoids unnecessary alert noise
• Increases operational awareness
• Enables security and infrastructure teams to take action at the right time

1. Inline Alert Rules

   Inline alert rules operate as part of predefined security policies in the system.

   These rules do not define new conditions; they generate alerts based on the criteria of the policies they are linked to.

   Supported policy types:

   • Sign-In Policies (Adaptive ZTNA - Beta)
   • Access Policies (Adaptive ZTNA - Beta)
   • Detectors & Responders (Adaptive ZTNA - Beta)

   These alert rules are used to observe and surface existing security decisions.

2. Legacy ZTNA Alert Rules

   Legacy alert rules exist to maintain compatibility with sign-in policies used before Adaptive ZTNA was introduced.

   • They do not contain independent condition definitions
   • Alerts are generated based on the criteria of the associated policy

   Policies included in this scope:

   • User Sign-In Policies (Legacy)
   • Administrator Sign-In Policies (Legacy)

   This structure ensures a seamless transition from legacy systems to the new alert architecture.

3. Custom Alert Rules

   Custom alert rules generate alerts based on specific infrastructure and connectivity properties, allowing you to monitor system health and performance from different perspectives.

   Property	Purpose
   Site Jitter	Measures packet delay variation; critical for real-time applications (VoIP, video)
   Site Packet Loss	Tracks packet loss ratio; high values indicate degraded connection quality
   Site Latency	Monitors end-to-end latency; a key metric affecting user experience
   IPsec Connector Status	Checks whether the component managing IPsec connections is healthy
   Tunnel Status	Monitors whether IPsec tunnels are online or offline

   These properties help detect not only outages but also performance issues that have not yet escalated into full disruptions.

Creating a Custom Alert Rule

From Alert Center → Rules, click Create Rule to proceed through three steps.

1. General

   Field	Description
   Title	Rule name displayed in alert lists and notifications
   Type	Custom
   Status	Enabled / Disabled
   Severity	Low, Medium, High, Critical

2. Conditions 🎯

   This section defines when the alert will be triggered.

   Multiple criteria can be added and grouped using AND / OR logic.

   Criteria Fields

   Field	Description
   Property	Defines the infrastructure or connectivity state to be monitored
   Item	Specifies which objects the property applies to (All, Any, or individually selected item)
   Operator	Defines how the property is evaluated
   Value	The state or threshold that triggers the alert

   ⚠️ Maintenance State Behavior

   When using site properties in alert rules

   • While the site remains in maintenance, alert generation is temporarily suspended for the organization.
   • This prevents false or unnecessary alerts during planned maintenance

   ℹ️ Using All / Any

   The All and Any options significantly simplify rule creation in environments with many sites, IPsec controllers, or IPsec tunnels. They allow you to:

   • Avoid updating rules when new gateways or components are added
   • Monitor large infrastructures with a single rule
   • Reduce operational overhead and configuration complexity

   For more granular monitoring, you can define specific sites or components as individual criteria rows. This approach enables more targeted alerting, especially for critical sites.

   🔔 Delivery Threshold Behavior

   Defines when an alert is generated after the defined conditions are met.

   Selecting the appropriate behavior helps prevent alert noise while ensuring important issues are detected on time.

   • Immediate

     An alert is generated as soon as the condition is met.

     Use this option when a single occurrence is critical and requires immediate visibility.

   • Repeated match

     An alert is generated only if the condition occurs multiple times within a defined time window.

     Use this option when short-lived or occasional spikes are acceptable, but repeated occurrences indicate a problem.

     Example scenarios

     • Site latency exceeds the threshold several times within a few minutes
     • An IPsec tunnel flaps repeatedly
     • Site packet loss spikes occur frequently in a short period </aside>

   • Consistent match

     An alert is generated only if the condition persists continuously for a defined duration.

     Use this option when you want to be alerted only for sustained and stable issues, not temporary fluctuations.

     Example scenarios

     • Site latency remains above the threshold for several minutes
     • Site jitter stays consistently high and affects real-time traffic
     • Site packet loss does not recover over a defined period </aside>

3. Notifications

   Notifications are optional. Configure this section if additional notifications are required when an alert is triggered.

   Channel	Description
   Email	System administrators or external email addresses
   Slack	Channel-based notifications (requires active Slack integration)
   Webhook	Sends event data to external systems

Saving the Alert Rule

Once all required fields are completed, click Save.

• If the rule is Enabled, alerts are generated when conditions are met
• Notifications are sent automatically if configured
• Monitoring continues until the rule is disabled

📊 Insights

The Insights screen goes beyond listing alerts by making trends, densities, and risk areas over time clearly visible.

This allows you to evaluate system behavior historically and understand the patterns that lead to alert generation.

From this screen, you can:

• View the most frequently triggered alert rules
• Analyze which sources generate alerts
• Compare whether security or infrastructure components generate more alerts

Top Triggered Alert Rules

Lists the alert rules that generated the highest number of alerts within the selected time range.

What does this show?

• Rules that continuously generate alerts
• Repeating problem scenarios
• Alert rules that may be:
  • Overly sensitive
  • Indicating persistent issues
  • Candidates for review or improvement

Alert Source Breakdown

Visually displays which system components generated the alerts, grouped by source:

• Access Policies (Adaptive ZTNA - Beta)
• Sign-In Policies (Adaptive ZTNA - Beta)
• Custom Alert Rules
• Detectors & Responders (Adaptive ZTNA - Beta)
• Sign-In Policies (Legacy)

What does this provide?

• Visibility into which layers generate the most alerts
• Comparison of security-driven vs. infrastructure-driven alerts
• Insight into how system behavior impacts alert generation

Severity Trend

This chart shows the distribution of alert severity levels over time.

Along the timeline, you can clearly observe:

• Periods with high concentrations of critical alerts
• Time ranges dominated by medium or low severity alerts
• Unexpected spikes or anomalies

Why is this important?

• Is the system becoming more stable over time?
• Do critical alerts cluster around specific hours or periods?
• Did a configuration change affect alert behavior?

All of these questions can be answered directly from this chart.

Updated March 10, 2026 16:36