An alert is a rule that watches your data and tells you when something crosses a line you care about: revenue falling short over the week, unsubscribes spiking on a single campaign, a list shrinking faster than usual. You set the condition once; SEINō checks it for you and gets in touch when it’s met. Alerts belong to the workspace, so everyone on the team sees and manages the same set.
What an alert watches
Section titled “What an alert watches”Every alert is built on one dataset: Campaigns, Subscribers, or another source connected to your workspace. Not every dataset can carry an alert — the picker lists the ones that can. From there you narrow and define what to watch:
- Date field decides which date the alert measures against, and defaults to the dataset’s own. On campaign data that is the difference between send date and event date: whether a campaign’s results sit on the day it went out, or on the days people opened, clicked and bought.
- Filters limit which rows count, by dimension: one campaign, one channel, one region. Filters are optional; without them the alert watches everything in the dataset.
- Conditions are the tests on a metric: revenue is less than 10,000, unsubscribe rate is greater than 2%. An alert needs at least one, and when it has several they all have to hold for the alert to fire.
- Duration is the rolling window the condition is measured over, a weighted average of the metric across the days you choose, from 1 to 365. A three-day window smooths out a single quiet Sunday; a one-day window reacts to it.
You can also group by a dimension to watch each value on its own, rather than the dataset as a whole. See Grouping by a dimension.
Grouping by a dimension
Section titled “Grouping by a dimension”Grouping changes how a condition is measured. By default the condition looks at the whole dataset at once. Grouped by a dimension, it’s checked separately for each value of that dimension, and the alert fires as soon as any one value crosses the line, naming the value that did.
Say you watch deliverability — the share of your emails that reach the inbox — across three markets (NL at 99%, BE at 99%, DE at 70%), and you want an alert when it drops below 85%. The same numbers give opposite results depending on whether you group:
Without grouping
| Market | Deliverability |
|---|---|
| NL | 99% |
| BE | 99% |
| DE | 70% |
| Checked as one | 89% |
89% is above 85%, so no alert.
Grouped by market
| Market | Deliverability |
|---|---|
| NL | 99% |
| BE | 99% |
| DE | 70% |
| Lowest market (DE) | 70% |
70% is below 85%, so DE alerts.
Without grouping, the two healthy markets prop up the average and DE’s problem stays hidden. Grouped by market, DE is judged on its own, so the alert fires and names it.
A grouped alert only checks the values that appear in the window it measures — the duration you set, plus a day. Values it has never seen in that window aren’t checked at all, so a market, campaign, or list that goes quiet is watched for the length of your duration and then drops out of the group. This gives duration a second job when you group: it sets how long something stays watched after it stops. For a worked example, see Alert when a campaign stops sending.
When an alert fires
Section titled “When an alert fires”A condition tests a metric in one of two ways:
- Against a fixed number. Greater than, less than, or equal to a value you set. The alert fires when the metric passes it. Use this when you know the line: revenue below 10,000, unsubscribe rate above 2%.
- Against normal behavior. Significantly higher, significantly lower, or significantly deviates need no value to set. The alert fires when the metric strays from its own recent pattern. Use this when you know a change matters but not where to draw the line.
SEINō checks your alerts a few times a day, after each refresh of your workspace data. They aren’t instant: a metric can cross its line and take a few hours to reach the next check. When you save an alert, it also runs once straight away.
Alerts read your data up to and including yesterday, never today. A campaign that went out this morning doesn’t count yet, and a problem you fixed today keeps showing until tomorrow’s data lands.
The last 30 days
Section titled “The last 30 days”Every alert carries a strip of 30 bars, one per day, ending yesterday:
- Red — the condition held that day.
- Green — it didn’t.
- Grey — the alert wasn’t evaluated, because it was one of your skipped weekdays.
The strip always covers 30 days, whatever duration you set. The line beneath it — would have triggered N times in the past 30 days — counts the red bars, so it’s a test against history rather than a count of what has happened since you made the alert. A new alert and a year-old one show the same number.
How you’re notified
Section titled “How you’re notified”When an alert fires it reaches you two ways, either or both:
- Email goes to the recipients you list, and you’re added by default. It names the alert, describes what tripped it, and carries any note you wrote.
- Webhook posts the alert to a URL you provide, so another system can pick it up. The body is a small JSON object:
{ "id": "…", "ruleId": "…", "workspaceId": "…", "title": "Weekly revenue below target", "workspace": "Acme", "note": "Check yesterday's send", "description": "The metric Revenue is less than 10000 in the past 7 days over all emails"}If you set up both, both go out. Neither is sent the instant an alert fires — they’re queued behind the check that triggered them, so allow a few minutes.
Managing alerts
Section titled “Managing alerts”Alerts live in the Alerting section, listed for the whole workspace. Because they’re shared, a change one person makes is the change everyone gets.
Enable, disable, and mute
Section titled “Enable, disable, and mute”Each alert carries a Status switch, Enabled or Disabled, so you can silence a rule without losing it. Disabling also closes whatever the alert currently has open, so switching it back on starts the rule fresh — which is the way to be notified again about something it has already reported once.
Ignore alert on specific days skips chosen weekdays, so a metric that’s always quiet on weekends doesn’t fire a false alarm. Skipped days aren’t evaluated at all, and show as grey bars in the alert’s 30-day strip.
Edit, duplicate, and remove
Section titled “Edit, duplicate, and remove”From the list you can edit an alert’s rule at any time, duplicate one as the starting point for a similar alert, or remove it for good. Removing an alert deletes it for the whole workspace.
Why don’t I get an email every day an alert stays red?
You only get one. SEINō emails you on the first day a condition starts holding, and stays quiet while it keeps holding — otherwise the same alert would reach you every day until you fixed it.
If the alert clears and then goes red again, that counts as a new one, and you get another email. And if you grouped by a dimension, it emails again when a new value starts violating, even while the first is still open.
Who can create and edit alerts?
Anyone in the workspace. Alerts aren’t tied to a role or to the person who made them, and there’s no separate view-only access: every member can create, edit, and remove any alert. A change one person makes is the change everyone gets.
Why didn’t my alert fire the moment the metric crossed the line?
Alerts are checked a few times a day, after each refresh of your workspace data, not the instant a value changes. A metric can cross its line and take a few hours to reach the next check.
What happens on a day I told the alert to ignore?
The condition isn’t evaluated at all, so the alert can’t fire that day, and the day shows as a grey bar in its 30-day strip. If the metric is still over the line on the next active day, it fires then.
Can I try an alert before relying on it?
Yes. As you build it, the setup screen shows how many times the rule would have fired over the past 30 days, and saving it runs one check straight away, so you see whether it’s tuned right before you depend on it.