Alerts

Alerts watch your data so you don’t have to open the dashboard to find out something broke. A rule checks one metric over one time window and notifies you by email, webhook, or both.

The page is split: your rule cards and recent activity on the left, the builder on the right. You get up to 10 rules per project.

Two kinds of rule

Threshold — a value crosses a limit. “At least 500 signups in 15 minutes.” “At most 2 signups in 24 hours.”

Absence — there are no matching events at all. Absence fires when the count is exactly 0. This is the one that catches outages, and it’s the one most people forget to set up.

Rule fields

At least one channel is required. The submit button stays disabled until you’ve filled in an email or a webhook URL. A rule with nowhere to send is not a rule.

About the event name

Leaving it empty is a feature, not laziness. An absence rule with no event means “no traffic at all” — the site-is-down alarm.

Built-in $-prefixed events like $pageview are valid alert targets. That’s an exception: your own event names can’t start with $, but alert rules can point at the built-in ones. The dropdown lists events seen in the last 30 days.

How evaluation actually works

This is the part worth reading twice, because it explains every “why didn’t I get an alert” question.

Rules are swept every 60 seconds.

Interval gating. A rule is never re-queried faster than max(60 seconds, window ÷ 4). A 5-minute-window rule is checked every minute. A 1-hour rule is checked every 15 minutes. A 24-hour rule is effectively evaluated at most every 6 hours — so if you set a 24-hour absence rule and then break your tracking, expect the notification within about six hours, not within one minute. Choose the window with that in mind.

Edge-triggered notifications. You are notified once when a rule goes OK → FIRING, and once more when it goes FIRING → OK — that second one is a recovery notice. It does not re-notify every interval while the condition stays true. This is the key difference from naive alerting: a rule that’s been firing for two days sends you two messages total, not two hundred.

Editing a rule resets it. Saving an edit — and also pausing or enabling a rule — resets its state to OK and clears the last value, so the changed condition gets evaluated fresh instead of inheriting the old rule’s state.

Aliases count. Alert counting honors your event aliases, the same as insights do.

Reading a rule card

Each card shows a status chip: OK in green, FIRING in orange, or Paused in gray with the card dimmed.

The detail line summarizes the rule — account_created ≥ 500 · 1 hour for a threshold, $pageview · 0 · 24 hours for an absence — plus “last value: N” so you can see what the last evaluation actually found.

Channel pills show the email address and the webhook host only, never the full URL with its secret path.

Buttons: Edit · Send test · Pause/Enable · ✕ Delete.

Recent activity

The last 30 firings, showing the kind (Fired / Recovered / Test), the rule name, the value that triggered it, a delivery failed flag if the channel didn’t accept the message, and the time.

Firings older than 90 days are purged.

What the notification says

The message is {head} — {project}: {body}.

The head is 🚨 {rule name} when firing, ✅ {rule name} recovered on recovery, or 🔔 Test: {rule name} for a test. Real examples:

🚨 Signup drought — MyApp: No account_created in the last 24h
🚨 Signup spike — MyApp: account_created = 812 (≥ 500) in 1h
✅ Signup drought recovered — MyApp: Recovered: account_created = 3 in 1h

Alert notifications are always in English. The app UI is bilingual, but a webhook can point anywhere and an email can go to anyone, so the recipient’s language is unknown. The notification text does not follow your interface language.

Email arrives as a branded message with a “View alerts” button that links straight back to the alerts page for that project.

Send test

Send test delivers through the real channels immediately, using the rule’s last value (or 0 if there isn’t one), and records a test entry in the activity feed. Use it every time you add a webhook — it’s the fastest way to find out you pasted the wrong URL.

If delivery fails you’ll see: “Test delivery failed — check the channel settings.”

Three rules worth having

No signups in 24 hours — Absence · Events · your signup event (account_created) · 24 hours. Catches the silent breakage where the form posts but the tracking call doesn’t.

Traffic spike — Threshold · Events · event name empty · is at least · 500 · 15 minutes. Tells you when you’re on the front page of something.

Site is dead — Absence · Events · event name empty · 1 hour. No events of any kind for an hour means the site, the CDN, or the script is gone.

Picking a window

Short windows are tempting and usually wrong. A 5-minute absence rule on a low-traffic site will fire on any quiet period — a lunch hour, a slow Sunday — and you’ll mute it within a week.

Start at 1 hour. It’s the practical choice until traffic is steady enough that a five-minute gap is genuinely abnormal. Then tighten.

Where to go next

• Alert webhooks — payload formats, Slack/Discord/Google Chat setup, and why a URL gets rejected
• Insights — build the chart you’d look at after an alert fires
• Event aliases — make sure the event you’re alerting on is the one you think
• Weekly Pulse — the scheduled summary, for everything that isn’t urgent