Threshold alerts

Fire one critical alert when matching events spike on a route — so a burst of 200 errors wakes you once, not 200 times.

A burst of errors is one problem, not two hundred notifications. A threshold alert rule watches a route, counts the events that match a condition, and — when the count crosses your threshold inside your time window — sends a single critical alert to a destination you choose.

Create a rule

Go to Alert Rules in the dashboard and click Create Rule. A rule needs five things:

Optionally add an event name pattern to narrow what counts. The pattern uses the same glob grammar as topic routing rules: * matches any sequence, everything else is literal, and matching is case-insensitive. payment-* counts payment-failed and payment-declined but not signup. The form has a live preview — type a name and it tells you whether it matches.

So "at least 20, error or higher, within 2 minutes, matching payment-*" reads as: if 20 or more error-level payment-… events land on this route within 2 minutes, alert me.

What counts

A rule counts every event accepted on its route that matches the level and pattern — including events your topic rules filter out before delivery. A rule measures what your application is reporting, not what got delivered somewhere.

Only real ingested events count. Alerts that rules emit are never counted by any rule, so alerts can never trigger more alerts.

When it fires

The window starts with the first matching event, not on a clock boundary. Once N matching events land inside the window, the rule fires immediately.

A rule fires at most once per window. If 500 errors arrive in your two-minute window, you get one alert, not 24. After the window elapses, the rule is armed again and the next qualifying burst fires a fresh alert. The dashboard shows when each rule last fired.

The alert event

Firing creates a real event on the route, so it shows up in your event feed and delivery log like any other event:

• Name — alert
• Level — critical
• Icon — 🚨
• Message — the rule name, the observed count, and the window
• Payload — the rule's id and name, the count that triggered it, the configured threshold, the window, and the level and pattern that were matched

The alert goes straight to the destination on the rule, bypassing your topics and their routing rules entirely. That is deliberate: an alert must land where you configured it, even if the topic rules on that route would have filtered it out.

Because alerts are critical, they are never held by quiet hours and never collapsed into a rollup.

Alerts are free

Synthetic alert events do not count against your monthly event quota. You are billed for the events your application sends, never for the alerts EventSend generates from them.

Multiple rules on one route

A route can carry as many rules as you like, and each one counts independently. That is how you escalate: "20 errors in 2 min → #eng-chat" and "200 errors in 10 min → your on-call webhook" can both watch the same route, and a large burst will fire both — one alert each, to different places.

If you only want one notification, use one rule.

Pausing and deleting

Pause a rule from its card to stop counting and firing without losing the configuration; resume it the same way. Changes take effect on the next event — there is no cache to wait out.

Deleting a rule's route or its destination deletes the rule too, since it would have nothing left to watch or notify.