Alerting and silences
Alerting turns a query into action. An alert rule watches a signal and fires when its condition holds; a silence mutes the resulting notifications for a while without touching the rule itself. The two are separate resources on purpose: rules are long-lived configuration, silences are short-lived exceptions.
Alert rules
Section titled “Alert rules”An alert rule is a named, workspace-scoped rule that evaluates an expression against one signal:
- Signal. A rule watches either metrics (a PromQL expression) or logs (a LogQL expression). The signal fixes which query language the expression is written in.
- Kind. An alert rule notifies when its condition holds. A recording rule instead precomputes an expression into a new series for cheaper querying later, so it carries no notification route.
- Pending duration. A rule can require its condition to hold for a stretch of time before it fires, which suppresses flapping on a brief spike.
When an alert rule fires, a notification route decides who hears about it. A route groups alerts by label, filters them with matchers, can nest child routes for finer targeting, and delivers to one or more receivers. A receiver is a webhook, an email address list, or a Slack channel. An alert rule must route to at least one receiver, which is why a rule with an empty route is rejected.
Alert rules are full lifecycle resources: you create, read, list, update, and delete them per workspace. Deletion is a two-step, mark-for-deletion then remove, so a rule cannot be dropped by accident.
Silences
Section titled “Silences”A silence suppresses notifications during a window, for a planned maintenance or a known incident, without disabling the rule that would otherwise page. A silence carries:
- Matchers. At least one label matcher (a label, a value, and whether the value is a regular expression) selects which alerts to mute. A silence with no matcher is rejected, since it would mute everything.
- A window. A start time and an end time, where the start must come before the end. The silence applies only inside that window and lapses on its own afterward.
- A reason. A required free-text comment recording why the silence exists.
- An author. The creator is stamped by the platform from the caller’s identity, never taken from the request body, so a silence cannot be attributed to someone else.
Silences are created and deleted, never edited. To change a mute, delete the silence and create a new one; that keeps the record of who muted what, and when, honest.
Operations
Section titled “Operations”Every mutating call in this service, creating or updating a rule, adding or removing a silence, changing a retention policy, sink, or ingestion config, returns an operation record rather than the resource. The operation comes back already completed, carrying the affected resource’s id, so you get a synchronous, auditable result for each change.