Set Up Cloud Alerts to Watch Your Server Metrics

Cloud Alerts keep an eye on your servers and tell you the moment a metric crosses a line you set: CPU pinned at 90%, disk filling up, a traffic spike. You pick what to watch and how to be notified (email, Slack, Discord), and the alert does the rest. An alert can even run an action for you, like spinning up another server when load stays high.

It's the simple way to stop babysitting graphs and find out about problems before your users do.

How it works

You define an alert on a server: a metric (CPU, RAM, disk, or network), a condition (for example "greater than 90"), and how long it has to stay that way before it counts. When the condition holds for that duration, the alert fires its actions: notify you through one of your notification channels, or create or destroy a server. After firing, it waits out a cooldown so you don't get spammed, and when the metric recovers it goes back to watching. You set everything up in the dashboard or over the API.

Before you start

• In the dashboard: my.cubepath.com → Cloud Alerts.
• Over the API: base URL https://api.cubepath.com, authenticate with Authorization: Bearer <token> (scopes trigger:read / trigger:write), and add X-Requested-With: XMLHttpRequest on writes. Get a token under Account → API Tokens.
• Set up at least one notification channel first if you want to be notified (below).

Step 1: Add a notification channel

A notification channel is where alerts send their messages. There are three types:

curl -X POST https://api.cubepath.com/triggers/notificators \
  -H "Authorization: Bearer $CUBEPATH_TOKEN" \
  -H "X-Requested-With: XMLHttpRequest" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Ops Slack",
    "type": "slack",
    "config": { "webhook_url": "https://hooks.slack.com/services/XXX/YYY/ZZZ" }
  }'

For an email channel, leave config empty. Channels are shared across all your alerts, so you set them up once and reuse them.

Step 2: Create an alert

An alert watches one target, on one metric, against one condition, and runs one or more actions when it trips.

curl -X POST https://api.cubepath.com/triggers \
  -H "Authorization: Bearer $CUBEPATH_TOKEN" \
  -H "X-Requested-With: XMLHttpRequest" \
  -H "Content-Type: application/json" \
  -d '{
    "project_id": 1,
    "name": "High CPU on web-1",
    "target_type": "vps",
    "target_id": "12345",
    "metric_type": "cpu",
    "operator": "gt",
    "threshold": 90,
    "duration_seconds": 300,
    "cooldown_seconds": 600,
    "actions": [
      { "action_type": "notify", "notificator_id": "<channel-uuid>" }
    ]
  }'

This says: "if CPU on VPS 12345 stays above 90% for 5 minutes, notify my Slack channel, then wait at least 10 minutes before firing again."

The pieces:

• target_type / target_id: vps, baremetal, or availability_group, and its id.
• metric_type: see the table below.
• operator: gt, lt, gte, lte, or eq.
• threshold: the value to compare against (CPU/RAM/disk are percentages).
• duration_seconds: how long the condition must hold before firing. Between 60 and 3600 (default 300).
• cooldown_seconds: minimum gap between firings, so a flapping metric doesn't spam you. Between 60 and 86400 (default 600).
• actions: one to ten, run in order when the alert fires.

Metrics you can watch

Bare metal servers support the network metrics only.

Actions

Each alert runs one or more actions when it fires:

Mix them freely (up to ten per alert) and set each one's order to control the sequence. notify is the common case; create_vps / destroy_vps are for simple automatic scaling or teardown.

Limits

What this doesn't do

• It's threshold-based, not anomaly detection. You tell it the line to watch; it doesn't learn "normal" on its own.
• It isn't a metrics dashboard. It watches the same metrics your server graphs show and acts on them; for browsing history and charts, use the server's metrics view. Each alert does keep a record of when it fired and recovered.
• Bare metal is network only. CPU, RAM, and disk alerts apply to VPS and availability groups.

API reference

GET    /triggers/notificators                 List notification channels.        (scope: trigger:read)
POST   /triggers/notificators   { name, type, config }   Add a channel.          (scope: trigger:write)
GET    /triggers/notificators/{id}            Get a channel.                     (scope: trigger:read)
PUT    /triggers/notificators/{id}            Update a channel.                  (scope: trigger:write)
DELETE /triggers/notificators/{id}            Delete a channel.                  (scope: trigger:write)
GET    /triggers                              List your alerts.                  (scope: trigger:read)
POST   /triggers   { name, target_type, target_id, metric_type, operator, threshold, actions }  Create an alert. (scope: trigger:write)
GET    /triggers/{id}                         Get an alert.                      (scope: trigger:read)
PUT    /triggers/{id}                         Update an alert.                   (scope: trigger:write)
DELETE /triggers/{id}                         Delete an alert.                   (scope: trigger:write)
GET    /triggers/{id}/history                 See when it fired and recovered.   (scope: trigger:read)

All requests authenticate with Authorization: Bearer <token> (or X-API-Key). Write requests also need X-Requested-With: XMLHttpRequest.