Alerts

Alerts turn monitoring into something that comes to you. A rule describes a condition; when it holds for long enough an incident opens, the right people are notified, and the incident closes itself when the condition clears.

Default rules

Every workspace with a monitored server gets a starter set of rules automatically, so a new workspace is protected on day one. They notify in-app only — Devpilot never emails you or posts to Slack until you enable that on a rule yourself. They cover: server unreachable, agent silent, disk almost full (85 %) and critically full (95 %), disk predicted to fill within a week, inodes almost exhausted, memory pressure, heavy swapping, sustained CPU saturation, load far above the core count, a failed service, a container restart loop, and memory growing steadily. Edit, disable or delete any of them under Monitoring › Rules; use Add default pack to restore the ones you removed.

Writing a rule

Incidents

An incident records when it opened, the peak and latest value against the threshold, and a snapshot of the server at that moment — the top processes by CPU and memory, disk usage, and any failed services — so the "what was eating it" question is answered without going back in time. A disk incident also carries the biggest folders and files on that mount and which of them is growing fastest; if the last folder scan is more than an hour old, Devpilot asks the agent for a fresh one so the answer arrives within a minute or two.

• Explain asks Devpilot's AI for a plain-language read of the incident — what happened, the most likely cause with the evidence that points to it, and up to five concrete next steps. It works only from what was captured: the incident's snapshot, deployments and script runs around it, the server's forecasts and its incidents from the past week. The explanation is saved on the incident so the whole team sees the same one; use Regenerate after new evidence arrives. Treat it as a well-informed first opinion, not a verdict.
• Acknowledge an incident when someone is on it. It stays open but is marked as handled.
• Resolve happens automatically when the condition clears. You can also resolve manually; if the condition is still true the rule opens a fresh incident on its next evaluation.
• Every incident is listed under Monitoring › Incidents for the workspace and under the server's Alerts tab. Open incidents also appear on the server overview and as a count on the Fleet page.

Silencing

Silence a rule for a period (for example during maintenance) from the rule list. While silenced, the rule keeps evaluating but does not open incidents; the moment the silence ends, a still-breaching condition fires.

Forecasts

Forecasts are recomputed every hour and shown in the Forecast card on the server overview, in the Full in column of the Disks tab, and as a full in ~N d chip on the Fleet page when a mount is expected to fill within 30 days.

• Disk full — the growth rate of each mount over the last seven days, projected to the date it runs out. A server that has only been reporting for a couple of hours gets an early estimate from its short history, marked as such, which firms up after a day. Mounts that are flat or shrinking say not growing. The estimate also names the folder growing fastest on that mount, and it feeds the Disk full in (days) rule.
• Memory — memory that climbs steadily for a day without dropping raises the Memory growing steadily signal, a common early sign of a leak. When the seven-day trend is upward you also see how long until the server reaches 90 %.
• Headroom — the 95th percentile of CPU and memory over the last seven days: what the server is spoken for at its busiest, and how much is left before it needs resizing.

Notifications

Nobody watches a dashboard all day, so an incident is delivered where you are:

• In-app — the bell in the sidebar shows unread notifications, and an alert that arrives while you are anywhere in Devpilot also pops up as a toast. Click a notification to open the incident on the server's Alerts tab; See all (or Notifications in the mobile menu) opens the full inbox.
• Email — off unless you switch it on. Tick Email owners & admins on a rule and its incidents are mailed to the workspace's owners and admins. Every alert email names the rule that sent it and where to turn it off, so nobody is left wondering why they received it.
• Slack, Discord and webhooks — any notification channel configured in the workspace can be attached to a rule.

An incident nobody acknowledges is sent again: critical every 30 minutes, up to three times; warnings once after two hours. Acknowledging or resolving the incident, or silencing the rule, stops the reminders. Recoveries are announced on the same channels.

Quota alerts

Plan-quota warnings (projects and apps approaching their limits) are a separate system configured under Workspace Settings › Usage, with their own thresholds and notifications.

Related pages

• Fleet — see open incidents per server.
• Server monitoring — incidents drawn on the timeline.
• Activity logs — the deploy or change that preceded an incident.