Platform thresholds and rules
Organisation-wide defaults, so every new object starts sensible.
Settings → Platform → Thresholds and rules sets the defaults everything else inherits.
What can be defaulted
| Default | Applies to |
|---|---|
| Check interval | New services |
For / Recovery / Cooldown | New rules |
| Severity | New rules |
| Routing | Where unrouted alerts go |
| Retention | New data |
| Disk, CPU, memory thresholds | New agent rules |
Why bother
The tenth service onboarded gets a slightly different threshold from the first, because somebody typed it again from memory. Six months later nobody can say which is the intended one.
A default is the intended one, written down once.
Defaults are not enforcement
Changing a default does not rewrite existing objects. A silent mass edit of live alerting is not something a settings page should do.
For applying a standard across many existing objects, use alert templates, which create real rules you can see before and after.
Suggested starting points
| Setting | Suggestion | Why |
|---|---|---|
| Check interval | 60 s | Below 30 s you mostly measure your own checker |
For | 5 min | Removes most transient noise |
Recovery | 5 min | Stops a premature "resolved" |
Cooldown | 30 min | Stops a threshold-straddling value paging repeatedly |
| Default severity | warning | Make critical a deliberate choice |
That last one matters. If new rules default to critical, everything becomes
critical, and then nothing is.
Related
Where this behaviour lives: frontend/src/app/platform/. If the code and this page disagree, the code is right — please fix the page.
Part of Administration — Settings, retention, platform thresholds and change tracking.