Notification Routing

Notification settings live under Settings → Notifications, in four pages: Destinations (where messages can go), Routing (the default destinations per event type), Digests and Delivery log (every outbound delivery, with retries and replay, see Webhooks).

Slack, Teams and Discord are webhook destinations: LogTide recognizes the URL and switches to the matching message format, and shows the destination with its own label and icon. Details are in Webhooks. You can send a test message before saving a destination. Secrets (routing keys, tokens, passwords) are not returned by the API after saving; leaving the field blank when editing keeps the stored value. Only owners and admins see destination webhook URLs.

Notifications belong to one of five event types: Alerts, Security detections, Security incidents, Uptime and Errors. For each notification LogTide applies the same three steps:

1. Destinations on the rule. If the alert rule, detection rule, monitor or error notification has enabled destinations of its own, those are used and nothing else.
2. Organization defaults. Otherwise the default destinations for that event type are used.
3. Email fallback. If neither exists and SMTP is configured, an email goes to the organization owners and admins. Without SMTP, nobody is notified.

The notification jobs and the routing preview share this code, so the preview cannot disagree with what is sent. Alert notifications also appear in the in-app notification panel for every member, whichever destinations are configured.

Settings → Notifications → Routing lists each event type with its default destinations, a short explanation, and a line stating what happens when none is set. Rules that override the defaults are listed below with links. Only organization owners and admins can change the defaults; members can read them.

Defaults for Alerts and Security detections are honored from 1.6. Before, they were never read, so alert rules and detection rules had to name their destinations explicitly.

Alert rules, detection rules, monitors and error notification settings can each pick their own destinations. This replaces the defaults for that rule; it does not add to them. A rule form shows a Will notify line with the result before you save, for example "Slack: #ops-alerts, PagerDuty: Platform on-call". Disabled destinations are ignored, so a rule whose only destination is disabled falls through to the defaults.

When no destination resolves and SMTP is configured, the notification is emailed to the organization's owners and admins, skipping disabled accounts. The rule is the same for every event type. Earlier versions mailed every member for some events and nobody for alerts and detections.

The preview answers "who would be notified?" for an event type, optionally with a destination selection from a form that is not saved yet. Any organization member can call it.

curl -G http://localhost:8080/api/v1/notification-routing/preview \
  -H "Authorization: Bearer YOUR_SESSION_TOKEN" \
  --data-urlencode "organizationId=ORG_UUID" \
  --data-urlencode "eventType=alert" \
  --data-urlencode "channelIds=CHANNEL_UUID_1,CHANNEL_UUID_2"

{
  "destinations": [
    { "id": "3b1c...", "name": "ops-alerts", "type": "slack" },
    { "id": "9a7e...", "name": "Platform on-call", "type": "pagerduty" }
  ],
  "fallback": null
}

eventType is one of alert, sigma (security detections), incident (security incidents), error and monitoring (uptime). type is email, webhook, slack, teams, discord or pagerduty. When nothing resolves, destinations is empty and fallback is "owners_admins_email" if SMTP is configured, otherwise null. Pass up to 50 comma-separated channelIds to preview a selection; omit it to preview the organization defaults.

The PagerDuty destination uses the Events API v2 with the routing key (integration key) of a PagerDuty service. Events opened by LogTide can be closed by LogTide, because every event for the same thing uses the same deduplication key:

LogTide severities map to PagerDuty as critical to critical, high to error, medium to warning, and low or informational to info. Triggers carry a link back to LogTide. Security incident and error events have no automatic resolve; close them in PagerDuty or let them age out there.

A threshold alert rule is either OK or Firing, and notifications follow the changes of state instead of every evaluation:

• Transition to firing - one notification when the rule starts firing, and an incident is opened. A sustained problem no longer produces a notification per minute.
• Re-notify - set renotify_minutes (5 to 1,440) to repeat the notification at that interval while the rule keeps firing. Leave it empty to never repeat.
• Resolved - when the rule returns to OK, LogTide sends the alert.resolved event to webhook, Slack, Teams and PagerDuty destinations, and resolves the incident. Nothing is sent by email or to the in-app panel for the resolution, and no resolved event is sent if the firing notification itself never went out (for example because the rule was snoozed the whole time).
• Snooze - mute a rule for 1 hour, 4 hours, 24 hours or until a date, up to 365 days (POST /api/v1/alerts/:id/snooze with until, DELETE to end it). A snoozed rule keeps evaluating and tracking its state but sends no triggers or re-notifications. Resolutions are still sent. If the rule is still firing when the snooze ends, you get one notification.

Threshold rules count every matching log in the last time_window minutes on each run. Rate-of-change rules keep their cooldown behavior and also gain state, incidents and alert.resolved. Disabling or deleting a firing rule resolves its incident. The rules table shows each rule as Firing, OK, Snoozed or Disabled, with its last trigger time.