Alerts

Alert rules per project — new issue, regression, spike — delivered by email or a signed webhook, with a per-issue cooldown.

Every stored event is grouped into an issue: the SDK’s fingerprint if it set one, else exception type plus in-app frames by module and function, else the normalised message. Issues track first and last seen, releases and hourly counts. Resolving an issue pins the release; an event from a release first seen later regresses it.

Rules are evaluated on ingest with a per-issue cooldown, and each notification is one journaled delivery: retried, then dead-lettered, never sent twice.

Kinds

Kind	Fires when
new_issue	A fingerprint is seen for the first time in the project
regression	A resolved issue receives an event from a later release
spike	An issue’s count in the last window minutes crosses threshold

Channels

• email — one message per notification, from the configured sender.
• webhook — a POST with the notification as JSON. With a secret on the rule, the body is signed: X-Tripline-Signature: sha256=<hmac>.

From the console

The project’s Alerts page lists rules and everything they sent, with each delivery’s attempts.

From the CLI

Against the database, with the production master key in the environment:

tripline -alert-rule 'project=grapevine-backend kinds=new_issue,regression channel=email target=you@example.com'
tripline -alert-rule 'project=grapevine-backend kinds=spike threshold=50 window=10 channel=webhook target=https://... secret=...'

Rules have a sealed secret field, so a rule created with the dev key blocks every runner in production until it is re-wrapped with the production key.