Skip to main content
Ankra Alerts help you stay informed about your cluster health, resource issues, and operational events with configurable notifications.

​
What are Alerts?

Alerts in Ankra let you define rules that automatically monitor your infrastructure and notify you when specific conditions are met. You can:
  • Monitor Cluster Health: Get notified when clusters go offline or agents disconnect
  • Track Resource Status: Watch for issues with GitOps repositories, add-ons, manifests, and stacks
  • Configure Conditions: Set up multiple conditions with AND/OR logic for precise alerting
  • Receive Notifications: Send alerts to any webhook-enabled service (Slack, Teams, PagerDuty, etc.)

​
How Alerts Work

​
Automatic AI Analysis

Every time an alert triggers, Ankra automatically starts an AI-powered analysis to help you understand what went wrong.

​
What Happens Behind the Scenes

  1. AI Analysis Resource - When conditions are met, Ankra creates an AI Analysis resource to track the investigation
  2. Analysis Job - A background job is scheduled to collect and analyze data
  3. Data Collection - The job gathers:
    • Pod status and container states
    • Kubernetes events (warnings, errors)
    • Container logs (recent output)
    • Job results and error messages
  4. AI Analysis - Ankra’s AI processes the data to identify:
    • Root cause of the issue
    • Severity assessment
    • Affected resources
    • Recommended actions
  5. AI Incident - Results are saved as an AI Incident for review
View all AI Incidents in the AI → Inbox. Each incident includes the full analysis, affected resources, and an interactive checklist of recommended actions.

​
Alerts Dashboard

The Alerts page displays key metrics at a glance: You can filter alerts by status (Active/Disabled) using the quick filter pills on the dashboard.

​
Alert Structure

An alert consists of rules, conditions, and webhook integrations:

​
Creating Alert Rules

Ask Ankra AI instead. In the chat, describe the alert you want - “page critical when any cluster goes offline”, “warn when a production stack is down” - and the assistant proposes a Create alert action with every rule spelled out (severity, clusters, conditions, cooldown). It is created once you confirm. The assistant only writes conditions the evaluator implements, so an alert it creates always fires when its condition is met. It can also mute an alert (Disable alert) or remove one (Delete alert), and the same tools are on the MCP server as create_alert, set_alert_enabled and delete_alert.
1

Name & Details

Configure the basic alert settings:
  • Alert Name: A descriptive name (e.g., “Production Resources Down”)
  • Severity: Choose Critical, Warning, or Info
  • Cooldown: Time in minutes before the alert can trigger again (prevents alert storms)
  • Clusters: Select “All Clusters” or choose specific clusters to monitor
2

What to Monitor

Select the resource type to monitor:

Cluster

Monitor overall cluster health including:
  • Cluster connectivity state
  • Agent status and availability

Cluster Resource

Monitor specific resource types:
  • GitOps - GitHub repository sync status
  • Addon - Add-on deployment health
  • Manifest - Raw manifest deployments
  • Stack - Stack deployment status
3

When to Alert

Define one or more conditions that trigger the alert. Multiple conditions can be combined using AND or OR logic.For Cluster monitoring:
  • Cluster State: Alert when cluster goes offline/online
For Cluster Resource monitoring:
  • Resource State: Alert on state changes (up, down, creating, updating, stopping)
  • Job Status: Alert on job outcomes (failed, timeout, blocked, etc.)
4

Notifications

Select which destinations (webhooks) should receive notifications when this alert fires. You can configure destinations in the Webhooks section.In addition to the alert’s own destinations, org-wide routing rules (Alerting → Destinations → Routing rules) can match alert firings by kind, severity, cluster, and source - for example, “every critical firing also goes to PagerDuty”.A destination that the alert already notifies directly is skipped by routing rules. That is a guarantee, not a coincidence of timing: a notification is delivered at most once per destination, so you can safely keep a destination attached to an alert and pointed at by a routing rule. See Notification routing for how rules are ordered, what Exclude and Stop on match actually do, and how to preview which destinations a notification would reach.If you have set a home channel, a critical or warning firing that no destination or routing rule handles falls back to the home so it is never missed.

​
Condition Types Reference

​
Cluster Conditions

Use these when monitoring Cluster resource type:

​
Cluster Resource Conditions

Use these when monitoring Cluster Resource types (GitOps, Addon, Manifest, Stack):

​
Condition Operators

For numeric threshold conditions, you can use these operators:

​
Alert Severity Levels

​
Viewing Alert History

Each alert tracks its trigger history. From the alert detail page, you can:
  • View Statistics: Total triggers, last check time, last triggered time
  • Review History: See when alerts triggered and what conditions matched
  • Analyze Patterns: Identify recurring issues across your infrastructure
Navigate to Alerts → [Alert Name] → View History to access the full timeline.
Still have questions? Join our Slack community and we’ll help out.