> ## Documentation Index
> Fetch the complete documentation index at: https://docs.slipway.sh/llms.txt
> Use this file to discover all available pages before exploring further.

# Usage alerts

> Get warned when a service holds CPU or memory near its limit, or its disk is filling, before it fails.

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

| Signal | Result |
| - | - |
| Memory above 85% of its limit for 3 minutes | Memory alert |
| CPU above 90% of its limit for 3 minutes | CPU alert |
| An out-of-memory kill | Immediate alert |
| A disk above 80% full | Disk alert |
| A disk that will fill within 3 days at its recent rate | Disk alert, before it reaches 80% |

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](/data/disks#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](/services/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](/services/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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.