Skip to content
Edka infrastructure automation platform Edka infrastructure automation platform Edka
SYS.DOCS // DOCS

Platform Notifications

Edka notifications are the platform-wide alert feed for operational issues across your organization.

They appear in three places:

  • the notification menu in the header
  • dashboard health and attention summaries
  • the full Notifications page at /notifications

What notifications cover

Section titled “What notifications cover”

Notifications are generated from cluster records, Kubernetes state, add-on state, and live monitoring snapshots.

Current notification categories are:

  • alert
  • cluster
  • kubernetes
  • addon
  • storage
  • security

Current severities are:

  • critical
  • warning
  • info

Active notification types

Section titled “Active notification types”

Edka currently creates notifications for:

  • clusters in failed or errored states
  • GitOps controllers reporting an error state
  • Kubernetes version updates
  • add-on failures and rollback failures
  • available add-on updates
  • not-ready nodes
  • failed or crashing pods
  • pods pending for more than 3 minutes
  • workload components with no ready replicas
  • workload components with partial readiness
  • unbound persistent volume claims
  • persistent volume claims at 85% usage or higher
  • persistent volume claims at 95% usage or higher
  • failed Kubernetes Jobs produced by CronJobs
  • cluster inspection failures during notification refresh
  • CronJob inspection failures during notification refresh

Each notification can include a cluster reference, a Kubernetes resource reference, and an action such as Open monitoring, Open diagnostics, Open add-ons, or Open CronJob.

Header menu

Section titled “Header menu”

The header notification menu shows active notifications and unread counts.

From the menu you can:

  • see unread and total active notification counts
  • identify critical, warning, and info items by severity
  • open the linked cluster, Monitoring, Diagnostics, Add-ons, GitOps, or CronJob page
  • mark one notification as read
  • mark all active notifications as read
  • open the full Notifications page

Read state is per user. Marking a notification as read does not resolve the underlying condition.

Notifications page

Section titled “Notifications page”

The full Notifications page shows active and resolved notification history.

You can filter by:

  • Active
  • Resolved
  • All

Each row shows:

  • severity and category
  • cluster name when available
  • title and description
  • resource kind, namespace, and name when available
  • first-seen time
  • last-seen time
  • resolved time for resolved notifications
  • how many refresh cycles observed the condition
  • the action link for the next operational step

The page supports manual refresh and Load more pagination.

Delivery channels and silences

Section titled “Delivery channels and silences”

Beyond the in-app feed, admins can route notifications outbound and suppress them on a schedule. Both are managed under /notifications.

Delivery channels forward notifications to external destinations:

  • channel types are email, slack, and webhook
  • each channel can filter by severity, category, cluster, event (triggered or resolved), and labels
  • a test action sends a sample delivery to verify the channel

Notification silences temporarily suppress matching notifications:

  • each silence is time-bounded with a start and end time
  • silences reuse the same severity, category, cluster, and label filters as delivery channels

Configuring channels and silences requires admin access.

Refresh behavior

Section titled “Refresh behavior”

Edka stores a current notification snapshot for each organization and also tracks notification occurrences over time.

Refresh behavior:

  • connected organizations are refreshed every 60 seconds
  • all organizations are refreshed every 5 minutes
  • the header menu receives live socket updates after a refresh
  • the full Notifications page refreshes its first page when live updates arrive
  • opening notifications on a cold snapshot triggers a refresh

If a condition disappears from the active snapshot, the active occurrence is marked resolved and remains available in history until retention cleanup.

History retention

Section titled “History retention”

Resolved notification history is retained by organization plan:

  • Free plans: 7 days
  • Standard and Starter plans: 30 days
  • Pro, Professional, and Enterprise plans: 90 days

Resolved history cleanup runs automatically.

Access scope

Section titled “Access scope”

Notifications are filtered by the clusters a user can see.

Owners, admins, and global admins can see organization-wide notifications. Users with narrower cluster access only see notifications for visible clusters, plus organization-level notifications that are not tied to a specific cluster.

Notifications vs Alerts

Section titled “Notifications vs Alerts”

Notifications are generated from built in Edka checks, current cluster state, and firing custom alert rules.

The Alerts tab in Clusters → Observability manages cluster-scoped PromQL alert rules and alert packs. Firing rules are surfaced through the same global notification system as built in cluster, Kubernetes, add-on, and storage conditions. See Cluster Alerts for the custom rule and pack workflow.

Section titled “Related docs”