---
title: "Cloud Alerts"
description: "Get notified by email, Slack or Discord when a server metric crosses a threshold, and optionally run an action such as creating a server."
category: "Deployment"
language: en
source: https://cubepath.com/docs/products/deployment/cloud-alerts
updated: 2026-10-28
---

# Cloud Alerts

Cloud Alerts watch your servers and tell you the moment a metric crosses a line you set — CPU pinned at 90%, disk filling up, a traffic spike. It's how you stop babysitting graphs and hear about problems before your users do.

Manage them on the **Cloud Alerts** page in [my.cubepath.com](https://my.cubepath.com).

## Step 1: add a notification channel

A channel is where alerts send their messages. Set one up once and reuse it across every alert.

| Type | What it needs |
|------|---------------|
| **Email** | Nothing — messages go to your account email |
| **Slack** | An incoming-webhook URL |
| **Discord** | A webhook URL |

## Step 2: create an alert

```steps
### Pick a target
Choose a **VPS**, a **dedicated server**, or an **availability group**.

### Choose a metric and threshold
Pick the metric, an operator (>, <, ≥, ≤, =) and a value.

![Alert condition with metric, operator and threshold](https://cdn.cubepath.com/img/docs/products/c46f1f78-6e2e-4ec1-96f3-8ad134793c7a.png)

### Tune the timing
Set a **duration** (how long the condition must hold) and a **cooldown** (minimum wait before firing again).

### Add actions
Add a **notify** action pointing at a channel — and optionally more.
```

A typical alert reads: *if CPU on web-1 stays above 90% for 5 minutes, notify my Slack channel, then wait at least 10 minutes before firing again.*

## Metrics you can watch

| Metric | Available on |
|--------|--------------|
| **CPU %** | VPS, availability group |
| **RAM %** | VPS, availability group |
| **Disk %** | VPS, availability group |
| **Network in / out** | VPS, **dedicated server**, availability group |

> Note: Dedicated servers support the **network metrics only**. CPU, RAM and disk aren't collected from the operating system — see [Metrics](/docs/products/deployment/bm-metrics) for why, and what to do instead.

## Duration and cooldown

These two settings are the difference between an alert you act on and one you learn to ignore:

- **Duration** (60–3600 s, default 300): how long the condition must hold before it fires. A 30-second CPU spike during a deploy shouldn't page anyone; five minutes at 95% should.
- **Cooldown** (60–86400 s, default 600): the minimum gap between firings, so a flapping metric doesn't spam the channel.

## Actions

An alert runs **1 to 10 actions** in order when it fires:

| Action | What it does |
|--------|--------------|
| **Notify** | Sends a message through a notification channel |
| **Create VPS** | Provisions a new server (name, template, plan and location) |
| **Destroy VPS** | Destroys the target server |

Notify is the common case. Create and destroy give you simple automatic scaling or teardown.

> Warning: **Destroy VPS destroys the alert's target.** Combined with a threshold that can be crossed by normal traffic, that's a machine deleting itself. Use a long duration and test the alert with a notify action first.

## Limits

| Thing | Limit |
|-------|-------|
| Alerts per organization | 20 |
| Actions per alert | 10 |
| Duration | 60 s – 3600 s |
| Cooldown | 60 s – 86400 s |

## What it doesn't do

- **It's threshold-based, not anomaly detection.** You define the line; it doesn't learn what's normal.
- **It isn't a metrics dashboard.** It watches the same metrics your server graphs show. Each alert keeps a record of when it fired and recovered; for browsing history, use the machine's [Metrics](/docs/products/deployment/vps-metrics) tab.

> Tip: You can open Cloud Alerts straight from a machine's Metrics tab with that machine pre-selected. A good first pair on any production server is disk above 85% and memory above 90% — both fail slowly enough that the alert gives you time to act.