Alerts

Alerts watch CPU and memory utilization across a project's environments and fire a notification when usage stays above a threshold for a sustained window. They're a project-level feature — set them once per (project, environment, metric); fire to every notification channel you've enabled.

How an alert fires

MetricCPU 85%The platform samples CPU and memory every minute.

Threshold> 80%Sample crosses the threshold you configured.

Held for5 minMust stay above the threshold for the evaluation period.

Alert firesA notification goes out across your enabled channels.

A spike isn't an alert. The platform samples metrics continuously; the threshold has to hold for the evaluation period before a notification goes out. That's what stops noisy alerting from short bursts.

Anatomy of an alert

Field	Meaning
Metric	cpu or memory. The aggregated utilization across the environment's services.
Threshold	Percentage (0–100). The alert evaluates metric > threshold.
Evaluation period	Seconds. The metric has to stay above the threshold for this duration to fire. Recommend at least 120s — shorter windows tend to flap.
Severity	low, medium, or high. A hint to you and your team about how urgently to respond. Doesn't change delivery — every alert fires through your enabled notification channels regardless.
Environment	Scoping. An alert watches one environment. To cover prod and staging, create one rule per environment.
Active	The rule's own enable switch. Plus a master switch on the project (below).

Project-level enable

There are two switches:

1. Per-rule active — toggles one specific alert on or off.
2. Project-level alert_enabled — kills the whole project's alert dispatch. When this is off, no rules in the project fire, even active ones.

Use the project-level switch to silence everything during maintenance windows without touching individual rules.

Notification delivery

An alert that fires is a notification, routed through whatever channels you have enabled — in-app, email, webhook (Slack/Teams). It lands in the deployment notification category. To control where alerts go, see Notifications.

Manage alerts

Create

1. Open the project.
2. Click the ⋯ menu next to the project name → Alerts.
3. Click Add alert.
4. Pick Metric: CPU or memory.
5. Set Threshold (e.g. 80%), Evaluation period (e.g. 300 seconds), and Severity.
6. Pick the Environment the rule should watch.
7. Click Save.

Edit, disable, delete

From the alerts list:

• Toggle the Status dropdown to flip a rule between Active and Disabled without losing its config.
• Edit (pencil icon) — change threshold, evaluation period, severity, or active state. Metric type and environment are fixed at create time; to change either, create a new rule.
• Delete (trash icon) — remove a rule entirely.

Project-level master switch

At the top of the alerts page, toggle Alerts enabled for the whole project.

Honest limits

• CPU and memory only. No disk, request-rate, latency, or custom-metric alerts today.
• Project + environment scope. You can't target a single service — the rule applies to the entire environment. Move noisy services into their own environment if you need different thresholds.
• No alert state surface. Alerts fire (a notification arrives), but there's no separate "currently firing" view today. Each fire produces one notification.
• No silencing or routing per alert. Severity is informational. To stop one specific alert without disabling it, set its active to false.

What's next

• Notifications — channels alerts go to, and how to route them to Slack or Teams.
• Auto-scaling — instead of alerting on CPU, let the platform add spherelets when CPU is high.
• Spherelets — the compute units whose CPU and memory are being watched.