Load average alert threshold limited to 1–100: how is this value interpreted?

[VAllens]

Hi,

I have a question about the alert configuration for 1-minute, 5-minute, and 15-minute load average. In the web UI, these three fields only accept values between 1 and 100. Before assuming this is a limitation, I'd like to confirm how this value is meant to be interpreted.

Specifically:

1. Is the entered value compared directly against the raw load average reported by the agent (e.g., setting 10 means the alert fires when load1 > 10)?
2. Or is it normalized relative to CPU/core count (e.g., 80 means load1 > logical CPUs × 0.8)?
3. Is any scaling applied internally before the comparison?

My understanding was that "load average" in Beszel maps to the standard Unix loadavg values (runnable + uninterruptible tasks), which are absolute numbers rather than percentages. However, I could not find anything in the official documentation explaining the 1–100 range or how the threshold is evaluated.

For context, my fleet includes:

• Beszel version: 0.21.0
• Host A: 80 cores / 160 logical threads
• Host B: 192 cores / 384 logical threads

If the field is a raw comparison, then on Host B a value of 100 corresponds to roughly 26% saturation (100 ÷ 384), so the alert would fire during perfectly normal operation. And a conventional rule such as "load1 > 1.5 × logical cores" would require a value near 576, which cannot be entered at all.

I also checked the Getting Started page (https://www.beszel.dev/guide/getting-started) and related docs, but did not see any explanation of this field's units, range, or comparison logic. I'm posting here mainly to make sure I'm not misreading the UI — not to request a change yet.

Could someone clarify the intended semantics? Once confirmed, I can decide whether my thresholds are simply misconfigured or whether the range needs revisiting for high-core-count hosts.

Thanks for the help.

[ska2704]

Your first reading is correct: it's a raw comparison against the load average, with no normalisation by core count and no scaling.

• In internal/alerts/alerts_system.go, LoadAvg1/5/15 take Info.LoadAvg[0/1/2] straight from the agent (unit ""), and the alert triggers when that value is greater than the threshold. With a "for N minutes" setting, it uses the average over that window. The tests in alerts_system_test.go cover exactly this: a threshold of 4 fires at 4.1 and not at 3.9.
• The range comes only from the UI. internal/site/src/lib/alerts.ts defines all three load-average alerts with min: 0.1, max: 100, step: 0.1 (so it actually goes down to 0.1, not 1). The CPU and memory alerts are percentages, but the load ones just reuse a 100 cap, which doesn't fit a 384-thread host.
• The server doesn't enforce it. The value field on the alerts collection has no min/max, and the alerts API only validates network-monitor thresholds.

So until the UI range changes, you can set a higher value directly on the record. Open the PocketBase admin (/_/, which needs a superuser), go to the alerts collection, find the LoadAvg1 / LoadAvg5 / LoadAvg15 record for Host B, and set value to e.g. 576. The hub reads it from there. Just don't touch that slider in the Beszel alert dialog afterwards: it can't show anything above 100, so saving from the dialog would bring it back under the cap.

Since you're fine with the semantics and the limit is purely in the UI, a feature request is probably the cleaner long-term fix: raise the max for the load-average alerts, or offer a "per logical CPU" option.

[VAllens]

@ska2704 Thank you for the detailed explanation and for confirming the behavior! The source code references and the PocketBase workaround are especially helpful. I've opened a feature request based on this: #2726

Appreciate the quick response!