Notifications
Tell your team when something happens on your shop — a new error, a lead, a sale, a site going down — in the places they already read.
You do this by adding destinations. A destination is one place alerts go: an inbox, a Slack channel, a Telegram chat, or a webhook into your own automation. Each one has a name you choose, and you tick the events it should receive.
A destination receives exactly the events it is subscribed to — nothing more, and there is no hidden "send everything" default.
Destinations live in Settings → Notifications. Anyone on the team can see them; changing, testing or copying them needs the admin role. A site can have up to 20 destinations.
Channels
| Channel | What you enter | Good for |
|---|---|---|
| One or more addresses, separated by commas (up to 10) | A shared inbox or a person | |
| Slack | An incoming-webhook URL | A team channel |
| Telegram | A bot token and a chat ID | A group chat or a phone |
| Webhook | A URL, and optionally a signing secret | n8n, Zapier, Make or your own server |
Slack and webhook URLs, Telegram tokens and signing secrets are stored encrypted and are never
shown again once saved — the form shows ******** in their place. Leave it as it is to keep the
saved value, or type a new one to replace it.
Slack
Create the webhook in your workspace: App Directory → Incoming Webhooks → Add to Slack, then
paste the URL (https://hooks.slack.com/services/…).
Telegram
- Create a bot with @BotFather and copy its token.
- Add the bot to your group or channel.
- Read the chat ID from
https://api.telegram.org/bot<token>/getUpdates.
Both are required: a token with no chat ID has nowhere to post.
Email
Mail is sent by the platform, so the server needs its SMTP_* settings — see
Configuration.
Webhook
Every event is a JSON POST. Each webhook destination has its own:
- Payload version — v2 (the default for a new destination) wraps every event in one envelope with your site's name and a dashboard link; v1 is the older shape, kept for automations built on it. See Outbound webhooks for both.
- Payload mode — summary (the default) or full, which adds the postal address, order notes and raw form fields to lead events.
- Signing secret — when set, every request carries an HMAC signature your receiver can check.
Events
| Event | Sent when |
|---|---|
| Errors | A new error is captured, or a resolved one comes back — at or above the severity you choose |
| Error spikes | This hour's error count is several times the recent average |
| Leads | Somebody submits a contact or enquiry form |
| Abandoned checkouts | A shopper fills in the checkout and does not pay (see the delay below) |
| Paid orders | A checkout is paid |
| Chats | A visitor starts a new conversation in your chat widget |
| Uptime | A monitored address goes down, comes back, or turns slow |
| Revenue silence | Visitors keep arriving but no order has been paid for longer than usual |
Severity for errors. A destination subscribed to errors hears about those at or above its floor: warning, error (the default) or critical. A Slack channel for the whole team can take criticals only while a developer's inbox takes everything from warnings up.
A chat's transcript is never sent anywhere. Email, Slack, Telegram and a webhook on payload version 2 are told that a chat started — who, when, how many messages, the page, and a link to it — and the conversation itself is held for you to read in the dashboard. A webhook on version 1 receives no chat event at all: its vocabulary was fixed before the event existed.
Webhooks get two extra events. A webhook subscribed to Paid orders also receives
lead.converted, so an abandoned-cart automation can cancel itself when the customer pays.
A ceiling for errors. One destination is sent at most 12 an hour error alerts. A bad deploy that throws a new error on every page is then a steady trickle rather than a flood, and the ceiling of a busy inbox never silences the Slack channel beside it — each destination counts its own.
Errors you have muted — for good, or until a date — never notify, and nor do errors caused by StorePilot's own collector. Every event is also recorded in the notification centre, whether or not any destination received it.
Testing a destination
Each destination has a Test button. It sends one harmless message through exactly the path a
real alert takes, with the saved credentials, and shows what came back — delivered, the error
the far side answered with, or not configured when something required is missing. A webhook
test is marked "event": "test" so your automation can tell a drill from the real thing.
Copying to your other shops
Copy puts the same destination on other sites of the same organization, credentials included. A site that already has a destination with that name and channel is skipped and named in the reply, so pressing it twice does not send you every alert twice.
Coming from channel settings or alert rules
Until September 2026 notifications were a set of per-site channel fields plus separate alert rules. Each configured channel became a destination subscribed to what it was already receiving, and each rule narrowed the destinations it governed; a rule's severity became the destination's severity floor. Conditions a destination cannot express — environment, fingerprint, message text, minimum occurrences — were dropped, and nobody was left without the alerts they had.
Abandoned checkout alerts
A checkout lead is captured the moment a shopper fills in the first field — which is usually a few minutes before the payment goes through. Two settings under Settings → Notifications decide when, and whether, you hear about it.
Wait before alerting is how long we hold the alert. Set it to 15 or 30 minutes and you stop telephoning people who are still on the payment page. If the shopper completes the purchase while we wait, the abandoned-cart alert is dropped and you are told about the order instead — you never lose the news, only the wrong version of it. The alert also goes if they close the tab; the delay costs you nothing except the wait.
Minimum cart value is a floor in your shop's own currency. Below it, nothing is sent to Slack, Telegram or email. The lead is still captured, still in the dashboard and still in your notification bell — the floor only stops the interruption.
Two things worth knowing:
- The basket is measured when the alert is due, not when it was captured. A shopper who keeps adding items and crosses your floor while you wait still reaches you.
- Setting a floor adds up to five minutes of waiting even with the delay at 0, because the basket has to be re-read before it can be compared. Alerts go out on a five-minute cycle, so any delay you set is a minimum rather than an exact time.
An alert is also dropped if somebody on your team has already reached out to that lead, or muted recovery for it, or if the lead was deleted — and if the platform was down for a day, an alert more than 24 hours late is dropped rather than arriving as stale news.
In-app real-time alerts
The dashboard uses a WebSocket connection (Socket.IO) to push notifications in real time to any browser that has the dashboard open. Alerts appear as a toast in the top-right corner without a page refresh.