Alerts & notifications
Alerts & notifications in the Settings area (Delivery) — route /automation/alerts.
Alerts & notifications lives in the Settings area of the dashboard, under Delivery.
At a glance#
| Dashboard route | /automation/alerts |
| Area | Settings (settings) |
| Group | Delivery |
| Platforms | Available for every app platform. |
| Note | This entry points outside its area's usual /{area}/{slug} pattern. |
What it does#
Alerts watch a metric against a threshold and notify you when it is breached. The metrics available are:
| Metric | Watches |
|---|---|
| Crash rate | Proportion of sessions ending in a crash. |
| Network failure rate | Proportion of requests failing. |
| Error count | Absolute count of errors. |
| App launch p95 | 95th-percentile launch time, in milliseconds. |
| Resource incidents | Static-asset incidents (web). |
When to use it#
Immediately, and this is the most under-configured page in the product. Every dashboard here is a page someone has to remember to open. An alert is the only thing that reaches you when nobody is looking, which is when incidents happen.
If you configure exactly one thing after integrating the SDK, configure a crash-rate alert.
Workflow#
Start with crash rate
It is the least ambiguous quality signal there is. A crash-rate regression is never a false alarm about whether something is wrong.
Set thresholds from your own baseline
Look at the metric's recent range before choosing a number. A threshold picked in the abstract either never fires or fires constantly.
Route it somewhere people read
An alert needs a destination — see Integrations for connecting one, and Alerts routing for deciding which alerts go where.
Delete alerts that cry wolf
An alert that fires without action being taken is worse than no alert: it trains everyone to ignore the channel, including for the alert that matters.
Permissions and prerequisites#
Requires the underlying metric to be reporting. A launch-time alert on a web app has nothing to watch. Delivery requires a configured destination.
Limits and edge cases#
Rate metrics on low volume are noisy. One crash in five sessions is a 20% crash rate. Set thresholds you can defend at your actual traffic level.
Alerts are evaluated on a schedule, not continuously. There is a delay between breach and notification.
Absolute versus rate matters. Error count grows with traffic; error rate does not. Choose whichever matches what you would actually respond to.
An alert with no destination is a record of intent, not a notification.
Troubleshooting#
Never fires. Threshold too high, the metric is not reporting, or there is no destination. Check in that order.
Fires constantly. Volume is too low for the rate metric, or the threshold is set at your normal range rather than above it.
Fires but nobody sees it. The destination is misconfigured — the classic case being a Slack bot that was never invited to the channel.
Where the data comes from#
Mounts the same routing panel as the Integrations hub, so a rule edited in either place is the same rule.
Served by
Integrations
Alerts