vpsmon CloudAlert settings
Open Alert settings from the dashboard. Thresholds and alert history are on the left; email and webhook integrations are on the right. Click Save after changing thresholds or integration switches. Verifying a new email address is a separate action.
Turning an integration off hides its fields. Turn it back on to show the saved address, URL, and format. Alert history stays visible while integrations are paused.
Thresholds and recovery
Thresholds apply to the servers in your workspace. Defaults are 90% for CPU, memory, and disk, and 180 seconds without telemetry for new workspaces. Existing saved thresholds are unchanged.
| Resource | When an incident opens | When it clears |
|---|---|---|
| CPU and memory | The one-minute average stays at or above the threshold for one minute. | The average stays below the recovery threshold for three minutes. |
| Disk | The latest reading of the fullest monitored writable disk reaches the threshold. | A later reading falls below the threshold. |
| Agent stopped reporting | Cloud has not received a fresh sample for the configured timeout. | A fresh sample arrives. |
The dashboard shows Reporting delayed after 60 seconds without accepted telemetry, independently of your alert timeout. This indicates a reporting gap, not proof that the server is down: the agent, network, or Cloud connection may be interrupted while the host keeps running. Recovery emails include the full gap from the last accepted sample to the next one.
CPU and memory normally recover at five percentage points below the alert threshold. With a 90% threshold, recovery starts below 85%. For thresholds below 10%, the recovery margin is half the threshold. Samples must keep arriving during the confirmation and recovery periods.
CPU spikes alone may not open an incident. The average and confirmation period reduce notifications from short bursts. Further high samples update the active incident. Start notifications are sent once per incident.
Email alerts
Missing-update alerts say Server is not responding, with the time since the last update. Longer gaps use minutes, hours, or days, such as "1 hour 17 minutes." The server may be offline, disconnected from the network, or its monitoring agent may have stopped. When updates arrive again, the recovery email says Server is responding again.
Your verified signup email is the default recipient. To change it, enter a new address on the right and click Verify address. Follow the link sent to that address. Your current verified recipient remains active until you confirm the change.
Use the Email alerts switch to pause incident and recovery emails, then click Save. Monitoring and incident history continue. Pausing cancels queued incident emails; resuming does not replay the cancelled notifications or incidents that started while paused.
Email and webhook switches work independently. You can receive both, use either one, or pause both. Account verification and password-reset messages are separate from incident notifications.
Alert history
Alert history lists recent email and webhook deliveries. This is delivery history; the server's Incident history lists the incidents themselves.
| Status | Meaning |
|---|---|
| Pending | Queued for delivery or waiting for a retry. |
| Sent | The email provider or webhook receiver accepted it. This does not prove an email reached the inbox. |
| Failed | Delivery stopped after a permanent error or the retry limit. |
| Cancelled | A pause or webhook destination change cancelled queued delivery. |
A delivery with retries shows its attempt count and latest error. For a failed email, check that the recipient is verified and look in its spam folder. For a failed webhook, check the receiver's logs and the HTTP status shown in history.
See Webhooks and Slack to add another notification channel.