SYS.DOCS // DOCS

Cluster Alerts

Use Alerts inside Clusters -> Observability to manage cluster-scoped metric alerts.

The Alerts workspace stores alert definitions in Edka and evaluates them from the cluster metrics store. Firing alerts feed into the same global Notifications system as built in cluster, Kubernetes, add-on, and storage checks.

Requirements

Custom alerts require VictoriaMetrics on the cluster. If VictoriaMetrics is not installed, you can still open the Alerts tab, but rules wait for the metrics store before they can evaluate.

Edka Agent evaluates saved rules inside the cluster and reports the latest series state back to Edka.

Some alert packs have extra metric requirements:

deployment, cluster health, and storage packs use kube-state-metrics, cAdvisor, or kubelet metrics
PostgreSQL packs use CloudNativePG metrics
ClickHouse packs use ClickHouse exporter metrics
Valkey packs use the built-in Valkey exporter, collected through the existing VictoriaMetrics annotated-pod scrape
NAT Gateway packs use Edka NAT Gateway metrics
host infrastructure packs use Node Exporter metrics

Alert rules

Open Alerts -> Rules to create, inspect, edit, or delete custom alert rules.

Each rule includes:

PromQL query
comparator and threshold
for duration
evaluation interval
severity: critical, warning, or info
labels and annotations
optional routing labels such as team or owner

Rules can be enabled or disabled without deleting them. Disabled rules remain saved but are not evaluated.

Test before saving

Use Test rule from the editor to run the PromQL query and threshold against VictoriaMetrics before saving.

The test result shows:

how many series were returned
how many series matched the comparator and threshold
the labels, values, and per-series match status for the returned series (up to the first several)

This is useful for checking metric names, label filters, and threshold units before the rule starts producing notifications.

Alert states

The Rules view summarizes current evaluation state:

OK: enabled rules with no matching alert series
Pending: rules with matching series that have not reached their for duration yet
Firing: rules whose matching series reached the configured for duration
Disabled: saved rules excluded from evaluation
Not evaluated: rules that have not reported a state yet

Rule rows also show the last evaluation time, matching series count, and any evaluation error reported by the evaluator.

Alert packs

Open Alerts -> Packs to install predefined rules as editable cluster alert rules.

Current packs include:

Deployments: rollout, availability, and pod restart alerts
Postgres: connection pressure, replication lag, blocked backends, and long transactions for CloudNativePG clusters
ClickHouse: replica availability, replication health, query failures, and disk pressure
Valkey: availability, memory and connection pressure, replication, persistence failures, and missing core metrics
Storage: high and critical persistent volume claim usage
Cluster Health: node readiness, pod phase, and container resource alerts
NAT Gateway: availability, failover, route, egress, security, and conntrack alerts
Gateway: Envoy Gateway proxy availability, 5xx rate, p95 latency, backend health per route, upstream timeouts, TLS handshake failures, and certificate expiry
Host Infrastructure: host root filesystem usage, inode usage, and sustained CPU alerts based on Node Exporter metrics

Pack rules are installed as normal custom rules. You can edit or delete them after installation. They do not count toward your plan’s alert rule limit, which applies only to rules you create yourself. Labels starting with edka.io/ mark pack rules and are managed by Edka.

Installing packs from this tab requires the Standard plan or higher. Packs Edka installs on its own, such as Postgres when a database becomes ready and Host Infrastructure, are included on every plan.

If a pack is already partially installed, Edka can install the missing rules. Rules with name conflicts are skipped instead of overwriting unrelated custom rules.

Gateway alert pack

Install Gateway from Alerts → Packs to add nine editable rules for Envoy Gateway entry points. They use the Envoy proxy metrics VictoriaMetrics already collects and evaluate once a minute, keeping each gateway class separate. Only customer-facing listeners count as traffic; readiness and stats probes do not.

Rule	Condition	Duration	Severity
Gateway proxy is not live	An Envoy proxy reports itself as not live	3 minutes	Critical
Gateway 5xx rate is high	More than 5% of requests return 5xx, with at least 60 requests in 5 minutes	5 minutes	Critical
Gateway p95 latency is high	p95 latency above 2 seconds, with at least 60 requests in 5 minutes	10 minutes	Warning
Route has no healthy backends	Every backend behind an `HTTPRoute` fails health checks	3 minutes	Critical
Route has unhealthy backends	At least one backend behind an `HTTPRoute` fails health checks	10 minutes	Warning
Gateway upstream timeouts	Backend timeouts above 1 per second	5 minutes	Warning
Gateway TLS handshake failures	TLS handshake failures above 1 per second	5 minutes	Warning
Gateway certificate expires within 14 days	Soonest-expiring certificate served by the class is under 14 days from expiry	1 hour	Warning
Gateway certificate expires within 3 days	Soonest-expiring certificate served by the class is under 3 days from expiry	1 hour	Critical

The 5xx and latency rules read 0 for a quiet gateway class instead of firing on a handful of requests.

Valkey alert pack

Install Valkey from Alerts → Packs to add ten editable rules. They use the existing Valkey exporter and evaluate once a minute, keeping each database and pod separate.

Rule	Condition	Duration	Severity
Metrics endpoint unreachable	Discovered exporter cannot be scraped	2 minutes	Critical
Server unavailable	Exporter cannot connect to Valkey	2 minutes	Critical
Memory usage high	Reported memory usage above 90% of nonzero maxmemory	10 minutes	Warning
Connection saturation	Connected clients above 80% of maxclients	5 minutes	Warning
Rejecting connections	New rejected connections in the preceding 5 minutes	2 minutes	Critical
Replica disconnected	Replica link to primary is down	2 minutes	Critical
Replication traffic stalled	Connected replica has received no primary traffic for over 30 seconds	5 minutes	Warning
Snapshot save failed	Latest background RDB save failed	2 minutes	Critical
AOF write failed	Latest AOF write failed while AOF is enabled	2 minutes	Critical
Core metrics missing	Reachable exporter lacks server status, or an online server lacks core metrics	10 minutes	Warning

Replication rules follow the reported role, including after promotion. Traffic inactivity measures the replication link, not replay delay. AOF write alerts apply only when AOF is enabled.

Memory usage is compared with Valkey’s configured maxmemory, not the container memory limit. Adjust the threshold for caches intentionally kept near capacity. Eviction rates and cache hit ratios have no default alerts because their expected values depend on the workload.

Endpoint alerts cover discovered targets. Use Cluster Health for pod and node failures and Storage for PVC pressure. The Valkey pack does not monitor Sentinel quorum or object-storage backup success; its RDB rule reports local snapshot failures. Use the database Backups tab to inspect stored backups and restore a snapshot to test one.

Node Exporter and host alerts

The host infrastructure pack depends on the Node Exporter add-on and VictoriaMetrics.

When node monitoring is enabled for VictoriaMetrics, Edka installs the Node Exporter add-on and configures VictoriaMetrics to scrape host metrics. Once both Node Exporter and VictoriaMetrics are installed, Edka can install the host infrastructure alert pack automatically.

Host alerts cover node-level pressure that Kubernetes object state alone cannot show, such as root filesystem usage, inode usage, and sustained CPU pressure.

Notifications

Firing custom alert rules appear in global notifications with the severity and labels from the rule. When the evaluator later reports that a rule no longer matches, the notification occurrence resolves and remains available in notification history until retention expires.

Read/unread state is separate from alert resolution.