Skip to main content

Alerting

Get a Slack/Discord/webhook notification when a new error shows up, a fixed issue comes back, or an error spikes — without having to keep the dashboard open. Off by default; enable per application in Settings → Plugins → Alerting.

The two pieces: channels and rules​

A channel is where a notification goes — a Slack incoming-webhook, a Discord webhook, or any generic webhook URL. A rule is when something fires and to which channel. One channel can back many rules (a rule points at exactly one channel, but nothing stops several rules from pointing at the same one) — e.g. one #eng-alerts Slack channel with a "new critical errors" rule and a separate "billing module spikes" rule both delivering there.

Creating a channel requires an https:// webhook URL, which is encrypted at rest (or stored in a clearly-marked plaintext envelope if you haven't set LOG_LENS_SECRET — the settings panel tells you which) and never shown back to the browser once saved; editing a channel lets you leave the URL blank to keep the existing one.

The three trigger types​

TriggerFires whenKey setting
new_errorA brand-new issue (never seen before) matches the rule's severity/module filter and has at least min_count occurrences.min_count
reoccurrenceAn issue you'd marked Fixed comes back.—
spikeAn issue's occurrence rate in the last hour is abnormally high versus its own 24-hour baseline.spike_factor, min_count

Every rule can also be scoped to specific severities (empty = any) and a specific module (empty = any).

How spike detection actually decides "abnormal"​

For each issue with at least one occurrence in the last hour, Log Lens computes an hourly baseline from the 23 hours before that (the last 24 hours, excluding the most recent one) and fires when:

  • the last hour's count is at least min_count, and
  • either the baseline is 0 and the last hour has at least 2 occurrences (so a brand-new pattern with no history still counts as a spike, but a single blip doesn't), or
  • the baseline is non-zero and the last hour exceeds spike_factor × baseline (default factor 3 — the issue needs to be firing 3× its normal hourly rate).

This means spike detection needs the issue to already have some occurrence history to compute a meaningful baseline for the non-zero case — a genuinely brand-new, high-volume issue is caught by the zero-baseline branch instead, not by the multiplier.

Why you won't get spammed​

Two independent mechanisms keep this from becoming noisy:

  1. Cursor-based, exactly-once evaluation. Each application has one cursor (the highest error-group id and status-history id seen so far). A scan only looks at what's new since the cursor moved, so every new error and reoccurrence is evaluated exactly once, never re-evaluated on the next scan. The cursor initializes to "now" the first time you enable the plugin — turning it on never replays your entire historical backlog as a notification storm.
  2. Consolidated delivery + cooldown. A burst of 40 new errors in one scan becomes one Slack message per matching rule (the first 5 named, then "…and 35 more"), not 40 separate pings. cooldown_minutes additionally enforces a minimum gap between deliveries for the same rule, regardless of how many more matches show up in between.

When it actually runs​

Alerting doesn't poll on its own schedule — it evaluates on every ingestion: the dashboard's "Process logs" button, a connector sync, the CLI import command, or an HTTP-ingested event all trigger a scan afterward as part of the standard finalize step. If nothing imports, nothing scans. For a schedule-driven install, this means alerting is only as fresh as your last scheduled sync/import (see Schedule syncing) — there's no separate always-on alerting daemon.

A plugin failure here is deliberately isolated: if a rule's delivery throws (bad webhook, network error, whatever), it's logged and the ingestion that triggered it still succeeds — an alert can never break the pipeline that fed it.

Delivery log​

Alert events (Settings → Plugins → Alerting) shows the recent delivery history — sent or failed, with detail (the matched issue summary, or the failure reason). Use Test channel to send a one-off test notification without waiting for a real trigger.