Epure alerts on new, regressed and spiking issues

A deploy goes out at 17:02. By 17:05 one TypeError has thrown 40,000 times in a retry loop, and a second, unrelated KeyError has appeared once on the checkout page. The question an alert has to answer is not how many events arrived. It is what changed, and which of the two needs you first.

Which errors trigger an Epure alert?

Epure alerts on three lifecycle changes of an issue, not on events. A new issue is the first event of a fingerprint Epure has not seen in the project. A regression is a resolved issue that receives an event from the release it was resolved in or a later one. A velocity spike is an issue whose event count in the last 15 minutes is more than 4 times its count in the 15 minutes before. A known issue that keeps firing at a steady rate sends nothing.

Two quieter signals sit next to these: built-in event milestones (an issue crosses a fixed count) and unique-user thresholds you set in alert rules. They appear in the in-app Alerts rail; you choose which ones reach a channel. Details of every kind: Alerts in the docs.

How does Epure detect a velocity spike?

Epure detects a velocity spike by comparing two consecutive windows for the same issue. With the default 15-minute window, an issue that logged 30 events from 16:47 to 17:02 and 140 from 17:02 to 17:17 has a ratio of 4.7, above the 4.0 threshold, so a velocity_spike alert fires. The previous window needs at least one event; a brand-new issue is covered by the new-issue alert instead. Self-hosted operators can change the window with EPURE_VELOCITY_WINDOW_SECS.

Velocity alerts and the spike valve are different mechanisms. The spike valve decides what Epure stores during a flood: 100 events per minute per identical error and 150 per throw site, with every occurrence still counted. Velocity alerts decide when you hear about a rate change. A loop can be sampled by the valve and still raise one spike alert.

When does Epure call an issue a regression?

Epure marks an issue as a regression when it is resolved and a new event arrives whose release is equal to or newer than the release it was resolved in. Releases compare part by part, so 2.10.0 counts as newer than 2.9.4. The issue moves to the Regressed state, its regression counter goes up by one, and a regression alert fires. An event from an older release, still running somewhere, does not reopen it.

Regressions need a release on your events. Set release in the Sentry SDK init (for example release: process.env.VERCEL_GIT_COMMIT_SHA in @sentry/nextjs) and resolve issues "in release". Without a release tag Epure cannot tell a fixed bug coming back from an old deploy still serving traffic, so it raises no regression alert. Workflow: Releases.

Where can Epure send error alerts?

Epure sends alerts to five kinds of channel: Slack, Discord, Telegram, email and a generic webhook. One channel can serve several projects and rules. Slack and Discord use their incoming webhook URLs, Telegram uses a bot and chat ID from the Bot API, and email goes to the recipients you list. You choose which alert kinds each channel receives, so regressions can go to Telegram while milestones stay in the app.

Generic webhooks are signed. Each request carries X-Epure-Timestamp and X-Epure-Signature, an HMAC-SHA256 (RFC 2104) over the timestamp, a dot and the raw body. Your receiver recomputes it with the shared secret and rejects mismatches or old timestamps. Outbound URLs that resolve to private or loopback addresses are refused. Payload fields and verification code: Webhooks API.

How does Epure keep alerts from flooding a channel?

Epure keeps alert volume low with four rules rather than a global rate limit, so a quiet channel never means a hidden error. A loop of 40,000 identical events produces one new-issue alert, then at most one velocity alert each time its rate jumps more than 4× in 15 minutes. The rules below decide what reaches Slack, Discord, Telegram, email or your webhook.

• One new-issue alert per fingerprint. Repeats of a known issue never re-send it.
• Snooze silences an issue. A snoozed issue sends no new-issue, regression, milestone or spike alert until the snooze ends by time, count or affected users.
• Rules can wait. Each custom rule has a cooldown in minutes and an optional environment filter, so production alerts can go to Slack while staging stays in the app.
• Floods stay one issue. Grouping and the spike valve keep a loop in one inbox row with an exact count, so there is one thing to alert on.

Alert volume follows from these rules more than from any threshold. In the 17:02 deploy above, the channel receives one new-issue alert for the TypeError, one for the KeyError, and at most one velocity spike for the loop if its rate keeps climbing. Three messages, each about a change.

What do Epure alerts not do?

Epure alerts cover errors, not performance or availability. There are no latency, throughput or uptime alerts, because Epure drops transactions and does not ping your site. If you need those, Honeybadger bundles uptime checks (see Epure vs Honeybadger) and Sentry offers metric alerts. Velocity state lives in memory, so a restart starts a fresh 15-minute window. Growth that stays under 4× per window never raises a spike alert, and there is no on-call rotation or escalation policy.

How do you test Epure alerts on your own project?

Testing Epure alerts takes one channel and two errors. Connect a Slack or email channel in Settings, then throw an error your project has never sent: a new-issue alert should arrive within seconds. Resolve that issue in release 1.0.1, send the same error tagged release: "1.0.2", and a regression alert should follow. Every plan includes alerts, including self-hosted: pricing.