Skip to content

Monitoring and Logs Updated 2026-05-27

Load alerts

Threshold-based email notifications when a container crosses a resource-usage percentage, sustained for a configurable time window.

When a container starts consuming more — or less — than expected, you usually want to know before the next page-load proves it. Load alerts are the platform’s threshold-based notification system: define a resource, a percentage, and a sustained time window; receive an email when the threshold is crossed.

Each container is created with a default set of pre-configured load alerts, so you get baseline notifications without setting anything up. You can adjust, disable, or add to them as the application’s behavior becomes clearer.

Configuring an alert

  1. Click Settings on the environment.

  2. Open Monitoring → Load Alerts.

  3. Existing alerts are listed here. The default set, if present, covers approaching limits on RAM, CPU, disk, inodes, and external network — the most common signals that an application is heading toward capacity trouble.

  4. Click Add in the toolbar (or pick Edit, Remove, Enable/Disable to manage existing alerts).

  5. Fill in the Add alert form:

    • Name — what this alert is called in the list and in the email subject.
    • Nodes — which layer the alert applies to. One alert can cover all nodes of a layer or one specific node.
    • Whenever — which resource to watch: Cloudlets (Memory, CPU), Memory, CPU, Network (out ext. + in ext.), Network (out ext.), Storage (disk space), Disk I/O, Disk IOPS, or Inodes.
    • Is — the comparison: > (above) or < (below), and a percentage (or a Mbps figure for network alerts).
    • For at least — the sustained duration. A spike that lasts shorter than this does not fire the alert. This is what keeps alerts from being noisy.
    • Notification frequency — how long to wait before re-sending if the condition stays true.

  6. Click Add. The alert appears in the list and starts evaluating immediately.

What the email looks like

When an alert fires, the recipient gets an email with:

  • The current consumption level.
  • A short recommendation on what to consider (typically, scaling).
  • A direct link to the node’s scaling limit so they can act without hunting through the dashboard.

If the environment is shared with other users, every share recipient gets the same email. The alert is per-environment, not per-user, but the notifications fan out across whoever has access.

Useful alert patterns

A few patterns worth setting up explicitly, beyond the defaults:

  • RAM above 80%, sustained 10 minutes. Catches gradual memory pressure before OOM. Lower duration if your application has slow GC cycles you do not want to miss.
  • CPU above 90%, sustained 5 minutes. Catches sustained CPU saturation. Short bursts are normal; multi-minute saturation usually means the workload outgrew the cap.
  • Network out external below 10% of expected, sustained 15 minutes. A “below” alert is useful for detecting traffic that has stopped — a frontend down, a CDN drained.
  • Disk above 85%. No duration needed; disk fills slowly and any breach is worth knowing about.
  • Disk IOPS above 80%, sustained 5 minutes. Catches storage throttling before it starts hurting response time.

The defaults already cover the most obvious cases, so add custom alerts for the patterns specific to your workload — a queue node, a CDN-origin layer, a database with predictable nightly batches.

Reviewing alert history

Beyond the current alerts, the platform stores a history of which alerts fired and when. From the same Monitoring panel:

  1. Open Monitoring → Events History. The Type dropdown is set to Load Alerts automatically.

  2. Pick a Period — day, week, month, or custom with a date range.

  3. The list shows each alert that fired in the window, with:

    • Date and time of activation.
    • Name of the alert.
    • Nodes the alert was configured for.
    • Condition that triggered it.
    • Result — success if the notification was sent, failure if the platform could not deliver it.

  4. Click a row to see the Details panel:

    • Loading Value — the resource level when the alert fired, with the cloudlet count in brackets.
    • Action — what the platform did (here, Send Notification).

The history view is what you reach for when something went sideways overnight and you want to reconstruct what the platform saw before it happened.

Where to go from here

  • Statistics monitoring — the data underlying the alerts, in graph form.
  • Monitoring consumed resources — how to read consumption against limits day-to-day.
  • Log files — the log side of the same diagnostic flow.