Alerts
An alert is a rule on one deployment: a metric, a threshold, how long it has to hold, and a severity. When the rule fires, Ownkube shows it in the dashboard and emails the organization owner. When the metric comes back inside the threshold, it emails again to say so.
What you can alert on
Section titled “What you can alert on”| Metric | Threshold unit | Measured as |
|---|---|---|
| CPU usage | % | Percent of the deployment’s configured CPU limit in use. |
| Memory usage | % | Percent of the configured memory limit in use (working set). |
| Container restarts | count | Restarts over a lookback window: 5, 10 or 30 minutes, or 1 hour. Default 10 minutes. |
Each rule has:
- Condition: rises above or drops below the threshold.
- Sustained for: how long the condition must hold before firing. Immediately, or 1, 5, 10, 15 or 30 minutes, or 1 hour. A short sustain catches blips; a longer one catches real trends.
- Severity: warning or critical. Severity changes how the firing is labelled, not who is notified.
- Enabled: switch a rule off without deleting it.
Create an alert
Section titled “Create an alert”- Open the deployment’s Overview tab and scroll to Alerts.
- Click New alert, pick a metric, set the threshold and direction, choose how long it must hold and a severity.
- Click Create alert. The rule starts evaluating within a minute and shows in the Alerts card with its state.
okctl alerts create <deployment-id> \ --name "High memory" \ --metric memory \ --threshold 85 \ --comparator gt \ --severity warning \ --for 300For restarts, add --window in seconds:
okctl alerts create <deployment-id> \ --name "Crash loop" \ --metric restarts \ --threshold 3 \ --comparator gt \ --severity critical \ --window 600okctl alerts list <deployment-id> shows the rules, okctl alerts update <rule-id> changes one (every flag above plus --enabled), and okctl alerts delete <rule-id> removes it.
When an alert fires
Section titled “When an alert fires”- The rule in the Alerts card turns to Firing with the value that tripped it.
- A notification appears under the bell in the dashboard header.
- The organization owner gets an email naming the deployment, the rule and the value. When the metric returns inside the threshold, a second email says the alert cleared.
- The firing and the clear are recorded on the deployment’s Activity tab.
okctl alerts firings lists recent firings across the organization; add --deployment <id> to narrow to one deployment and --limit to cap the list.
Suggested starting rules
Section titled “Suggested starting rules”| Rule | Why |
|---|---|
| Memory rises above 85%, sustained 5 minutes, warning | Catches leaks before the container is killed for running out of memory. |
| CPU rises above 90%, sustained 10 minutes, warning | The app is saturated; add replicas or turn on autoscaling. |
| Restarts rise above 3 in 10 minutes, critical | A crash loop. The Logs tab, filtered to level:error, has the reason. |
Limits
Section titled “Limits”- Rules belong to one deployment. Create the same rule on each deployment that needs it.
- Emails go to the organization owner. Forward or filter them at your mail provider if someone else is on call.
- Request-level metrics (status codes, latency) cannot be alerted on yet. If you need that, email support.
Metrics The charts the thresholds are measured against.
Health checks The other safety net: restart a replica that stops answering.
Rollbacks and activity Where firings land alongside rollouts and config changes.