Notifications and alerts
Who hears about new errors, and how alert rules reach email, Slack and webhooks.
New-error notifications
These need no setup. The project owner is notified:
- the first time a new kind of error appears in the project;
- when a resolved error happens again (at most once every 30 minutes for the same error);
- when an error first seen in an environment you don’t follow reaches one you do.
Each notification appears in the app, on the Notifications page, and is sent by email to the owner’s address with a link to the error. Further occurrences of an error you have already heard about don’t notify again. Only the owner receives these; to reach the rest of the team, add an alert rule.
Choosing environments
In Settings › Notifications you can turn these notifications off, or choose which environments trigger them. The default is production only. Leave the list empty to be notified about every environment. Errors sent without an environment always notify. Names are compared without regard to case.
Check your SDK’s environment
development unless you set environment, and the default notification setting ignores development. See Environments and releases.Alert rules
For anything beyond new errors, create a rule on the project’s Alerts pages with Create Alert Rule. A rule is checked against every log as it arrives.
Conditions
| Field | Matches when |
|---|---|
| Log Level | The log is at exactly this level. |
| Keyword | The message contains this text (case is ignored). |
| Service | The log’s serviceName is this value. |
| Environment | The log’s environment is this value. |
| Event Type | The log is of this kind: error, performance, network, console or interaction. |
| Response Time (ms) | A captured network request took at least this long. Logs that aren’t network requests also pass this check, so pair it with Event Type: network. |
| Frequency Threshold and Interval (minutes) | At least this many matching logs arrived within the interval. Leave the threshold empty to alert on every match. |
Fields you leave empty match anything. You can combine several conditions and require ALL or ANY of them.
Where alerts go
| Channel | What you provide | What arrives |
|---|---|---|
| One or more addresses | An email with the alert, its severity and the log message. | |
| Slack | A Slack incoming webhook URL | A message with severity, status, message and environment. |
| Webhook | Any HTTPS URL | A JSON POST with "type": "alert.triggered" and the alert under event. Failed deliveries are retried. |
| GitHub Issue | A connected GitHub integration | An issue for the alert. The same alert doesn’t open a second issue. |
Every triggered alert is also listed on the Alerts page. Webhook requests aren’t signed, so keep the URL private.
Other integrations
Cooldown, snooze and maintenance
- Cooldown. After a rule fires, it doesn’t fire again within its interval (10 minutes if you set none) while that alert is still active or acknowledged.
- Snooze. A snoozed rule is skipped until the snooze ends.
- Maintenance windows. While one is active, rules don’t fire for the logs it covers: all of them, or only certain services or environments.