Skip to main content
Usage alerts watch every running service against its own limits. When one holds CPU or memory near its allocation for a sustained window, slipway warns you: a toast and inbox notification, a warning card on the service with one-click fixes, and a message to your Slack, Discord or webhook channels if any are set up. They are on by default for every service, on every plan. There is nothing to set up.

​
What triggers an alert

Pressure has to hold across the whole window, so a single spike stays quiet. An out-of-memory kill skips the window, because the restart is the evidence. A disk skips it too: it only fills until someone acts, so the first reading over the mark is the alert. A disk with auto-grow on never alerts while it has room to grow. It is grown instead, and you get a receipt. It alerts only once auto-grow reaches its limit or cannot grow it. An alert that stays hot repeats at most every six hours, and recovery is silent: once usage falls well below the mark and stays there, the warning clears on its own.

​
Warning and critical

An alert opens as a warning. It escalates to critical when the failure stops approaching and arrives: CPU at 98% or more of its limit by default, memory at 95% or more, an out-of-memory kill, or a disk 90% full or due to fill within a day. Escalation notifies once more even inside the six-hour repeat window, and everything that renders the alert — the banner, the chip, the shaded chart windows — turns red. Both tiers are per-service settings. A latency-sensitive service can reasonably call 90% CPU an incident, so the critical marks are yours to move; they are held at or above the warning marks, and an out-of-memory kill is critical whatever the marks say.

​
What you see

The service shows a warning card on its Overview and Metrics tabs with the current usage, a sparkline against the limit, and the fixes that apply to it:
  • Add a replica, where the service can scale out. One confirm, then a redeploy at the new count.
  • Enable auto-resize, so automatic compute grows the allocation on its own next time.
  • Adjust compute, for changing the allocation by hand. Applied to the running pods in place, no restart.
The project’s service list carries a small warning chip on the affected row, the project page leads with an incident strip naming each hot service, and the projects list marks any project with a live alert — so an incident is visible from the very top of the console. The notification itself opens a breakdown on the Notifications page with the same actions. On the service’s Metrics tab, the CPU and memory charts draw a dashed line at the service’s limit and shade every alert window, so a spike three days ago still explains itself. Episodes are kept as history alongside the metrics.

​
Tuning or muting

Each service has a Usage alerts section on its Compute tab: the warning and critical marks per axis, the sustained window, and a switch to mute the service entirely. Thresholds accept 50 to 99 percent; the window accepts one minute to one hour. Muting a service stops the warnings but the charts still record what happened. Every alert also lands on the service’s Events feed. View opens the incident: a panel with the episode’s numbers and its usage chart, shaded and frozen to the window where it happened — live and updating while the alert is still open.

​
Alongside automatic compute

The two are designed as a pair. While automatic compute can still grow a hot service, slipway lets it act and you get the resize receipt instead of a warning. You are only alerted when nothing automatic is coming: auto-resize is off, the service is pinned at its growth ceiling, horizontal autoscaling owns the hot axis, or the cluster cannot resize it live.