System architecture
The core is one n9e process: no dependencies for testing, MySQL and Redis for production, several instances sharing them for a cluster, and n9e-edge for multi-site.
Processes and roles
Most deployments need only the n9e process; n9e-alert and n9e-pushgw are roles that can be split out, n9e-edge serves multi-site setups, Categraf collects on hosts.
Storage
Nightingale ships with an embedded TSDB for onboarding; this page explains its limits and when to switch to Prometheus or VictoriaMetrics.
Business groups
Business groups are the permission boundary: every rule, target and dashboard belongs to one, and membership decides who can see or change it.
Core object model
The three objects everything else hangs off: a data source is queried by a rule, and a rule that trips produces an event.
Lifecycle and severity
An event is identified by rule plus label set and passes through firing, ongoing and recovered; S1 / S2 / S3 change nothing mechanically — they signal urgency.
Labels and annotations
Labels decide which event this is; annotations decide what the notification says. They are not interchangeable.
Evaluation and recovery
A rule does not fire on the first high value: three timing parameters and a small state machine decide when it first fires, when it recovers and whether it flaps.
Noise reduction and routing model
Mute rules, subscriptions, pipelines and notification rules are not alternatives: they act on an event in a fixed order, which is why a muted alert can still page.
Authentication and permissions
Two layers: roles decide which pages and endpoints are reachable, business-group membership decides which data can be touched; UI, HTTP API and MCP share the model.