Alert rules

An alert rule decides which Issues open Incidents — and therefore which events page the on-call engineer. Rules attach to an app and evaluate every event Nightlamp ingests for that app.

How a rule fires

Each ingested event is normalized and fingerprinted into an Issue. Every active alert rule for the event's app is evaluated against the new event; if any rule matches, an Incident opens (or an existing one is updated) and the notification fan-out runs.

Rules respect a cooldown — once a rule fires for an Issue, it won't fire again for that same Issue within the cooldown window (default 5 minutes). This is the difference between "alert me once when this starts" and "alert me on every single event".

Condition types

new_issue — fires the first time a fingerprint is seen. Good default for "I want to know about every new failure mode".
threshold — fires when an Issue's event count crosses a configurable threshold within a rolling window. Tune to your traffic; a payments service might want 5 events / 60 s, a low-volume admin tool 1 event / 60 s.
regression — fires when a previously resolved Issue starts producing events again. Catches "we shipped a fix and it broke again" without spamming you on the initial outage.

Filtering

Rules can scope to a specific environment (e.g. production) and a minimum level (e.g. error and above). This keeps dev-environment noise out of the on-call queue without a separate rule per env.

Defaults we ship

Every new app gets one default rule: new_issue in production, error level minimum, 5-minute cooldown. That's enough for a smoke-test integration; tune from there in the alert rules editor on the app's detail page.

Native uptime monitors come with their own implicit alerting — a confirmed-down probe opens an Incident regardless of alert rules. See Status reference for how monitor states map to incident states.