App Resource Thresholds

Skitflow can watch every app's CPU, memory, and disk usage and fire a notification when one stays over a configured limit for too long. It reuses the same per-app usage samples as Swarm Monitoring, so it works whether the app is a compose stack service or a plain container.

Configure

Open Dashboard → Monitoring → Alerts and use the App Resource Thresholds card:

• Enable threshold alerts — off by default; no checks run for the organization until this is on.
• CPU / Memory / Disk threshold (%) — defaults are 80 / 80 / 85.
• Sustained checks — consecutive over-threshold checks required before an alert fires (default 3). Checks run every 5 minutes, so the default is a 15-minute sustained breach.
• Cooldown (minutes) — minimum time between repeat alerts for the same app and metric (default 60).

Only one config exists per organization — it applies to every app in it. Saving requires the app_thresholds.update custom-role permission (organization owners/admins always have it); viewing requires app_thresholds.read.

Alert lifecycle

A background tick runs every 5 minutes for each organization with alerts enabled. For every app and each of the three metrics, it compares the latest usage sample to the configured threshold:

• Breach starts the first time a metric goes over its threshold — no notification yet.
• Breach notified once the breach has lasted sustainedChecks consecutive checks and cooldownMinutes has elapsed since the last notification for that app/metric.
• While still breaching but waiting on the sustained window or cooldown, no new notification is sent.
• Recovered is sent once the metric drops back to or under the threshold, but only if a breach notification had actually gone out (a breach that never got sustained long enough to notify clears silently).

Notifications are delivered to every configured channel that has the App Resource Threshold toggle enabled — see Notifications. A notification failure for one app/metric is logged and does not stop the rest of the tick from being processed and persisted.

API

The dashboard talks to this over two self-hosted-only tRPC procedures:

POST /api/trpc/appThreshold.get
POST /api/trpc/appThreshold.update

get takes no input and lazily creates the organization's config row (with the defaults above) on first read:

{
  "organizationId": "org_123",
  "enabled": true,
  "cpuPercent": 80,
  "memPercent": 80,
  "diskPercent": 85,
  "sustainedChecks": 3,
  "cooldownMinutes": 60
}

update accepts a partial patch — any subset of the fields below, all optional:

{
  "enabled": true,
  "cpuPercent": 90,
  "memPercent": 85,
  "diskPercent": 90,
  "sustainedChecks": 2,
  "cooldownMinutes": 30
}

cpuPercent / memPercent / diskPercent accept 1–100, sustainedChecks accepts 1–60, and cooldownMinutes accepts 0–1440. Each update is recorded in the organization audit log as an app-threshold-config update.