Before you start
Notifications are per user, per project.
Each project member controls their own email preferences. Self-hosted installs must also have SMTP configured and at least one Sidekiq worker running, because most notification work happens outside the web request.
Read the setup requirements before debugging notification delivery.
Choose a path
Use the page that matches the user's intent.
Errors
Error triage alerts
Use when the user wants immediate email about one error group needing attention.
Health
Project health alerts
Use when the user wants to know when the whole project is noisy, slow, or missing check-ins.
Routing
Workflow routing
Use when the user wants assignment and status-change mail for their work or matching project changes.
Reports
Digests and delivery
Use when the user wants daily or weekly summaries, hourly caps, or quiet hours.
Ops
Operational notices
Use when the user wants deployment, intake, quota, retention, or archive failure mail.
Defaults
The default setup favors important immediate alerts.
| On by default | Off until enabled |
|---|---|
| New error groups, reopened error groups, check-in monitor alerts, intake/quota warnings, retention/archive failure notices. | Digests, project-wide spikes, performance alerts, lifetime milestones, frequent single-error alerts, and deployment summaries. |
Next steps
Keep the overview short; use the subpages for exact controls.
When something does not send, start with setup requirements, then open the path that owns the alert type. The troubleshooting page has the short operator checklist for SMTP and worker issues.