Alerts

Alerts have two halves. A rule is a standing condition you care about; an event is one occasion on which that condition fired. You tune the first and triage the second, and NuPaaS seeds a starting set of both so a new organization is not silent by default.

Rules and events#

Manage both at /orgs/<org>/alerts. The page also shows your organization's log and trace volume over the last 15 minutes and hour, so you can tell an alert storm apart from a telemetry outage at a glance.

A rule is enabled or disabled, and can additionally be muted for a period without being disabled — the distinction matters during an incident you already know about. An event carries a message, an optional title and details, a severity, and a read marker.

Who can manage alerts#

Only owners and admins can create, edit, mute or delete an alert rule, or mark and resolve an event. The server enforces this. Every alert procedure requires the org:update capability, which the role matrix grants to owners and admins only, and the check runs in the RPC middleware before the handler. A direct API call from a member or a viewer is refused, and so is a call from an API key whose scope is read-only — whatever role that key was minted at.

The page itself also redirects other roles to the projects list. That redirect is a convenience, not the control: it only affects the browser route. The alerts surface is also feature-gated, so it may be unavailable to your organization even if your role would allow it.

The default rules#

A starter set is auto-seeded for every organization and shown on the page before your own rules. They are ordinary rules — tune or disable any of them.

The backup rule's 26-hour window is deliberate: it is slightly longer than a daily schedule, so a job that runs a little late does not fire an alert but a job that never ran does.

Rule fields#

Triage#

Events are listed newest first. Acknowledging one marks it read — there is a single read marker per event rather than a separate acknowledge state, so the feed distinguishes only between events someone has looked at and events nobody has.

Reading an event does not resolve the underlying condition. If the rule is still true, it fires again.

Silence a rule#

A rule can be muted for a number of minutes. The mute has an explicit expiry recorded on the rule, and the rule resumes on its own when that passes — there is no permanently muted state to forget about.

Procedure vocabulary#

If you are driving alerts through the API rather than the panel, these are the six operations that exist:

ListRules       # rules, cursor-paged
CreateRule      # name + condition
UpdateRule      # rename, re-condition, enable or disable
ListEvents      # fired events, newest first
MarkEventRead   # acknowledge one event
SilenceRule     # mute a rule for N minutes

Acknowledging an event is MarkEventRead. There is no separately named acknowledge operation, and no delete operation for a rule — a rule you no longer want is disabled.