Alerts & notifications

Route new issues, spikes, and security events where they need to go.

Alert rules live on the project. Each rule has a trigger (when to fire), zero or more filters (what to fire on), and one or more channels (where to send the notification). Rules are evaluated in the consumer worker as events flow in, so latency from ingest to notification is typically a few seconds.

Triggers

Trigger	Fires when…
New issue	An event arrives with a fingerprint that has never been seen on this project before.
Spike	Event count for an existing issue exceeds a threshold relative to its rolling baseline (e.g. 10× in 5 minutes).
First seen in release	An existing issue starts firing again after being marked resolved, or first appears in a new `release` tag.
Security categorized	An event is tagged as a CSP violation, scanner probe, auth spike, geo anomaly, or XSS attempt. See Security signals.

Filters

Filters narrow a trigger so you can have, e.g., a different rule for the production environment than for staging. Each filter is a key/operator/value triple. Available keys:

environment — production, staging, etc.
release — exact match against the event's release tag.
severity — fatal, error, warning, info.
error_type — e.g. TypeError, NetworkError.
tag:<name> — match against any custom tag on the event.

Operators: equals, not_equals, contains, regex.

Channels

Email

Pick which team members get notified. The default is everyone with maintainer role or higher.

Per-user, in Account → Notifications, each member can opt into combine daily digests: instead of one email per matching rule, GlitchReplay batches all matches into a single 9am-local-time digest.

Slack

Paste a Slack incoming webhook URL into a channel. Messages include the issue title, count, severity, and a deep link back to the dashboard.

Webhook

For routing into PagerDuty, OpsGenie, or your own systems. Webhooks POST a signed JSON body:

{
  "event": "issue.new",
  "rule_id": "alr_…",
  "project": { "id": "prj_…", "slug": "your-project" },
  "issue": {
    "id": "a3b1c9d82e4f5a1b",
    "display_id": "gr_k9f2qab",
    "title": "TypeError: cannot read properties of undefined (reading 'id')",
    "fingerprint": "…",
    "severity": "error",
    "environment": "production",
    "release": "abc1234",
    "first_seen": "2026-04-25T10:14:00Z",
    "url": "https://glitchreplay.com/projects/your-project/issues/gr_k9f2qab"
  },
  "delivered_at": "2026-04-25T10:14:03Z"
}

Each delivery includes an X-GlitchReplay-Signature header — an HMAC-SHA256 of the raw body using the per-rule signing secret shown in the dashboard. Verify it before trusting the payload.

SIEM webhook (Business plan)

On Business and Enterprise, you can additionally route the entire stream of security-categorized events to a SIEM-formatted webhook (CEF or ECS), with no rule filtering. Useful for compliance pipelines that need an immutable copy of every CSP violation, scanner probe, and auth spike.

Snoozing and throttling

Per-rule throttle — a rule fires at most once per N minutes per issue. Default is 5 minutes for spike rules, no throttle for new-issue rules.
Issue snooze — on each issue detail page, you can mute notifications for that fingerprint for 1h / 24h / 1w / forever.
Resolved → re-opens — if you resolve an issue and a new event arrives, that triggers first seen in release only if the release has changed.

Best practices

Start with a new issue, environment=production rule going to email. Watch for a few days, then add channels.
Spike rules are noisy on small projects. Wait until you have at least a week of baseline before turning them on.
Route security categorized events to a separate channel. The signal is different from app errors and the people who should see it are usually different too.
For oncall, use the webhook channel into PagerDuty rather than Slack — Slack mentions get muted, pages don't.

Next: define PII rules so events are scrubbed before they reach storage and notifications.

← Back to home