Open the machine → Metrics tab in my.cubepath.com.
What's charted
| Chart | What it shows | What a spike usually means |
|---|---|---|
| CPU Usage | Percentage of the plan's vCPUs in use | A busy process, or a plan that's too small. Sustained 100% on a shared plan is the classic reason to resize |
| Memory Usage | RAM in use vs. the plan's total | Approaching the limit means the kernel will start swapping or killing processes (OOM) |
| Disk Usage | How full the disk is | Above ~90% many services (databases, package managers) start failing |
| Disk I/O | Read and write throughput | Heavy sustained I/O often points at swapping or an unindexed database |
| Network Traffic | Receive and transmit throughput | A sudden outbound spike can mean an attack, a runaway backup job, or bandwidth overage |
Time range and live mode
Pick a range from the selector: last hour, 3 / 6 / 12 hours, 24 hours, 3 days, 7 days or 30 days. Short ranges show fine detail; long ranges are averaged, so brief spikes flatten out — when you're chasing a short incident, zoom in first.
Toggle Live Mode to keep the charts refreshing on their own while you watch a deploy or a load test.
Turn a threshold into an alert
Watching graphs doesn't scale. Click Create Alert and you land in Cloud Alerts with this machine already selected.
An alert watches one metric (CPU, RAM, Disk %, Network in/out) and fires when it crosses your threshold. Two settings keep it from becoming noise:
- Duration: how long the threshold must be crossed before it fires. A 30-second CPU spike during a deploy shouldn't page you; five minutes at 95% should.
- Cooldown: how long to wait before firing again for the same condition.
TipA good first pair of alerts on any production machine is disk above 85% and memory above 90%. Both fail slowly enough that an alert gives you time to act.