OPERATING

Monitoring, logs and alerts

Read metrics and logs, set alert rules, and get told on Discord or by email when something breaks.

Metrics for every server and container, logs for every application, and alert rules that tell you when something crosses a line — on Discord, Slack, by email or to a webhook of your own.

Metrics

Two levels, sampled continuously and kept as history:

Server: CPU, memory and disk for the machine, used and total. This is what alert rules read.
Container: Per-container CPU, memory, network in/out and block I/O — for an application, a database or a Linux instance.

You see the servers you have access to through project membership; a platform administrator sees the fleet. Reading metrics needs monitoring:view, which is part of the read-only role.

Container history is pruned automatically — it is the fastest-growing table in the system, and unbounded metric retention becomes a disk problem long before it becomes a useful archive.

Logs

Three log streams exist and they answer different questions — see deployments for when to reach for which. Container logs are the live stream from the running process, and they are the ones you want when the application is up but misbehaving.

If your application writes logs to a file inside the container rather than to stdout, the dashboard shows you nothing. Docker collects stdout and stderr — anything else is invisible to every tool in this category, not just this one.

Alert rules

A rule is a server, a metric, an operator, a threshold and a channel:

TEXT

cpu     >=  90    → Discord
memory  >=  85    → email
disk    <   10    → Slack

Thresholds are percentages, so memory >= 90 means ninety percent regardless of how much RAM the machine has. Metrics available: cpu, memory, disk. Operators: >, >=, <, <=, =.

The direction of the comparison changes what is measured, and this is the useful part. disk >= 90 means “used crossed a ceiling”. disk < 10 means “free fell below a floor” — the reading you actually want from that phrasing, not “the disk is nearly empty”. CPU has no free counterpart, so the operator never flips it.

Rules are evaluated every thirty seconds against the most recent sample. Two behaviours worth knowing:

A crossed rule does not re-fire every thirty seconds. Repeat notifications are suppressed — an alert that shouts every half-minute for an hour trains you to ignore it.
A server that has stopped reporting stops firing alerts. Its last sample is frozen, and a frozen sample would re-announce a resource alert forever. The host being offline is surfaced on its own, as itself.

That second behaviour matters when you design your alerting: a silent rule is not proof that things are fine. Watch server reachability as its own signal, not as the absence of resource alerts.

Where alerts go

Channel	Needs
Email	SMTP configured on the install. See installation.
Discord	A channel webhook URL.
Slack	An incoming-webhook URL.
Webhook	Any URL of yours — for a pager, an internal bot, or your own on-call tooling.

A channel that fails — a revoked webhook, an SMTP server that refuses — is logged and skipped. It never takes the evaluation loop down, so one misconfigured destination cannot stop every other rule from firing.

Send a test notification when you create the rule. A webhook URL with a typo in it is indistinguishable from a quiet server until the night you needed the alert.