Alert Rules
By default, every alert your site produces goes to every channel you have configured. That is the right behaviour for a small shop and the wrong one the moment you have a noisy fault, a staging environment, or a colleague who only wants to hear about checkout.
An alert rule narrows it: when an event looks like this, send it to these channels.
The rule that applies when you have no rules
A site with no rules for an event type routes that event to every configured channel. This is the original behaviour, kept deliberately, so that turning the feature on changes nothing until you actually write something.
Two consequences worth stating, because they are the two things people get wrong:
- The fallback is per event type. A rule about errors does not silence leads — leads still go everywhere, because you have no lead rule.
- Once you have a rule for a type, that type is governed by your rules. If your only error rule fails to match an error, that error is sent nowhere. That is not the fallback case; that is your rule doing what you asked.
Writing one
Settings → Notifications → Alert rules.
A rule has a name, an event type, at least one channel, an optional set of conditions and an optional throttle.
| Event type | Fires on |
|---|---|
| Errors | A new error, or one that had been resolved and came back |
| Leads | A new lead, including an abandoned checkout |
| Error spikes | The hourly spike detector — see Spike Detection |
| Uptime changes | A site going down, and the same site coming back |
| Conversation | A visitor starting a new chat on your site |
Revenue silence (revenue_silence) | Your shop taking visitors and no orders, in hours that normally sell — and the message that says it started selling again |
A revenue silence is deliberately hard to trigger. It needs visitors in the window, no paid order in it, and the same hours of the same weekday to have sold in the weeks before — so an ordinary quiet night is not an alert, and neither is a shop that never sells at 4 a.m. It arrives once for the whole silence, however long it lasts, and closes with the first order. The window is twelve hours by default; setting it to zero switches the rule off for that site.
Channels are Email, Slack, Telegram and Webhook (n8n) — the same four you set up in Notifications.
Conversations are the one event type that never reaches the Webhook (n8n) channel. A chat transcript is held for you to read in the dashboard, and forwarding it to an address outside the platform is a different promise from the one the privacy policy makes — so a chat alert goes to email, Slack and Telegram only, and a rule naming the webhook for it simply sends nothing there.
Conditions
Every condition is optional, and the ones you set are ANDed — all of them must hold. An empty condition matches every event of that type.
| Condition | Matches |
|---|---|
| Severity | notice, warning, error, critical |
| Type | For errors: js, ajax, promise, php, console, resource. For uptime: up, down |
| Source | For errors: frontend, backend |
| Environment | Whatever your site reports — production, staging, and so on |
| Fingerprint | One exact issue. Copy it from the error's detail page |
| Message contains | A case-insensitive substring of the error message |
| Minimum occurrences | Only once the issue has been seen this many times |
A list you leave empty is not a constraint. A list you fill in does not match an event that has nothing in that field — a rule filtering on environment will not fire for an error whose environment is unknown.
Error spikes carry no attributes at all, so a spike rule is only ever about which channels the spike goes to.
There is deliberately no page or URL condition for errors. An error in StorePilot is an aggregate keyed on its fingerprint and does not have a single URL to match against.
Throttling
Throttle is minutes, and 0 means never. While a rule is throttled it stays quiet; the clock
starts from the last time that rule actually sent something. This is what stops a flapping fault
paging you on every round trip.
Throttling is per rule. Two rules matching the same event throttle independently, and a rule that matched but had no configured channel to send to does not start its own clock.
A rule cannot invent a channel
Routing is always intersected with the channels you have actually configured. A rule naming Slack on a site with no Slack webhook sends nothing to Slack — silently, not as an error — and if none of a rule's channels are configured, the rule does nothing at all.
A channel counts as configured when its credential is present: Slack needs its webhook URL, Telegram needs both the bot token and the chat ID, the webhook channel needs its URL, and email needs at least one recipient address.
If you are not sure a channel works, use Send test beside it rather than waiting for a real alert. It sends one real message through the same sender with the same stored credential, and a dead webhook reports as a failure rather than as silence.
Who can change them
Anyone who can see the site can read the rules. Creating, editing and deleting them needs the admin role — the same bar as the notification settings the rules route into.