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.
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 |
|---|---|
| Nothing — messages go to your account email | |
| Slack | An incoming-webhook URL |
| Discord | A webhook URL |
Step 2: create an alert
- 1Pick a targetChoose a VPS, a dedicated server, or an availability group.
- 2Choose a metric and thresholdPick the metric, an operator (>, <, ≥, ≤, =) and a value.
- 3Tune the timingSet a duration (how long the condition must hold) and a cooldown (minimum wait before firing again).
- 4Add actionsAdd 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 |
NoteDedicated servers support the network metrics only. CPU, RAM and disk aren't collected from the operating system — see 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.
WarningDestroy 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 tab.
TipYou 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.