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 page at Settings → Notifications

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

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
automatic image updates: an image that was updated, an update awaiting approval, checks that keep failing, and a newer image that can’t be used
vulnerabilities: a known exploited CVE with a fix waiting, critical fixes left uninstalled for three days, and security fixes in a Kubernetes patch release
firing alert rules, including the Workloads, Cluster Health, and Storage pack rules for node readiness, pods that fail, cannot start, or stay pending, workloads without ready replicas, failed CronJob runs, and persistent volume claims that are unbound or nearly full

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

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, Alerts, Diagnostics, Add-ons, or GitOps page
mark one notification as read
mark all active notifications as read
open Settings → Notifications

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

Notifications page

Settings → Notifications shows active and resolved notification history. Delivery channels and maintenance windows are tabs on the same page.

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

Beyond the in-app feed, admins can route notifications outbound and suppress them on a schedule. Both are managed under Settings → 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

Maintenance windows hold deliveries for a set time. Alerts keep firing in the cluster; only the outbound messages are held. Under Maintenance, pick what to silence:

All alerts: every notification, every cluster
Clusters: everything from the selected clusters
Specific alerts: only the alerts you tick from the active list

Then pick a duration (15 minutes to 1 week), start it now or at a later time, and optionally narrow the window by labels. Any active notification in History also has a Silence menu that holds just that alert for the chosen duration.

While a window is active, History shows what is being held and the Maintenance tab carries a count. Silenced notifications show a Silenced marker with the time left. A window can be extended (up to 7 days from its start) or ended early.

Configuring channels and silences requires admin access.

Outage emails without a channel

When a cluster’s Kubernetes API is unreachable and no delivery channel would send that notification, Edka emails the cluster owner, or the organization owner when the cluster has none:

after the API has been unreachable for 1 hour
after 24 hours, when the cluster is marked disconnected
when the cluster reconnects, if an outage email went out

A maintenance window that covers the outage holds these emails too. The 24-hour email always goes out when it announces that a disconnected cluster will be removed from the account. Clusters Edka never reached send no outage emails.

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

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

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

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.