Alerts
Set thresholds on any metric so you hear about a region drifting out of range instead of discovering it later.
Alerts watch your metrics and tell you when something moves outside the range you expect. Configure them at /home/<team>/monitoring/alerts.
What an alert is
An alert is one metric, a range, a scope, and how you want to be told.
| Setting | What it does |
|---|---|
| Name | How the alert appears on the dashboard and in notifications |
| Metric | The metric being watched |
| Minimum | Fires when the value drops below this |
| Maximum | Fires when the value rises above this |
| Severity | Warning or Critical |
| Scope | Which parts of your service area it applies to |
| Notifications | In-app, email, or both |
| Enabled | Whether it is currently active |
You must set at least one of minimum or maximum. Set both to define a band — "active clients per region should stay between 80 and 140".
Scope
Four options, from broad to narrow:
| Scope | What it watches |
|---|---|
| All | Everything in the team |
| Regions | Specific regions you choose |
| All postal areas | Every individual area, evaluated separately |
| Specific postal areas | Only the areas you choose |
The distinction between the region scopes and the area scopes matters. A region can look healthy on average while containing an area that is badly out of range — watching areas individually catches that, at the cost of more alerts.
Start at the region level. Narrow to specific areas only when you have a known problem you want to keep an eye on.
Severity
Warning — worth knowing about, act when convenient.
Critical — needs attention now.
The distinction is yours to define; the platform just carries it through to the dashboard and notifications. Use it consistently or it stops meaning anything.
Notifications
In-app notifications appear in the notification bell. On by default.
Email is off by default. When you turn it on for an alert, you specify the address it goes to — which can be a shared operations mailbox rather than an individual.
Each person has their own toggle for alert emails in team Settings (/home/<team>/settings). If someone says they are not receiving alert emails, check their personal preference before you check the alert configuration.
Creating an alert
- Go to
/home/<team>/monitoring/alerts. - Create a new alert and give it a name that says what it means — "Downtown overloaded" beats "Alert 3".
- Choose the metric and set the thresholds.
- Choose the scope.
- Choose the severity and how you want to be notified.
- Save.
Editing works the same way; alerts can also be disabled rather than deleted, which is useful when you want to pause one during a known period of disruption.
Choosing thresholds
This is the part people get wrong, and it is worth being deliberate about.
Look at your history first. Open the dashboard and see what your metrics have actually done over the past few months. Set the range around your normal, not around a target you would like to hit.
Start wide. A threshold that fires constantly gets ignored within a week, and then it is worse than no alert at all. Better to catch the serious cases at first and tighten later.
Set a small number of alerts. Three alerts you act on beat thirty you filter into a folder.
Use both bounds where it makes sense. A region that is far under range is also a problem — it is capacity you have paid for and are not using.
Revisit them. Thresholds that made sense at 1,500 clients do not at 2,500.
Reading alert history
The dashboard shows violations over time, not just what is wrong now. That is the more useful view:
- A persistent violation — sitting outside range for weeks — is structural. It will not resolve itself, and it is a candidate for rebalancing.
- An intermittent violation — crossing the line and coming back — usually means the region is at the edge of its capacity, and something like a staff absence tips it over.
- A one-off spike is often a data problem. Check the sync history before reacting.
Alerts are per team
Each team has its own alerts. There is no organization-wide alert configuration — if you run several teams and want the same alerts across all of them, you set them up in each.