Alerting
Reach your team the way they actually want to hear about it
Slack, email, SMS, a voice call, or a generic webhook for your own tooling, configured per project, per trigger.
Channels and triggers, configured independently
Each notification rule pairs exactly one trigger with one channel, so a project can have as many rules as it needs: new issues to Slack, regressions to email, spikes paging someone by voice call, a missed heartbeat hitting a generic webhook that feeds your own on-call tooling. A phone number (for SMS or a call) has to be in E.164 format, a leading + and country code, the same format Twilio itself requires for both the destination and the sending number.
Reserve Call for what actually deserves to wake someone up. It's the most intrusive channel by design, so it's the right fit for a spike rule on a payments path, not a routine new-issue notice on a low-traffic internal tool.
One rule per trigger/channel pair, as many as a project needs.
Spikes don't flood the channel
A spike rule watches a rolling time window you set (event count over the last N minutes) rather than firing on every single occurrence once a threshold's crossed. Once it fires for a given issue, it won't fire again for that same issue for 30 minutes, a fixed cooldown, regardless of how many more events land in the meantime.
That means a genuinely sustained spike still gets exactly one alert every half hour it stays active, not one alert per event, which is what would turn a real incident into a flood of near-identical pings in the same channel.
Every trigger/channel combination is available from the same form.
Delivery happens off the hot path
Notification evaluation and delivery run in a background job, kicked off after an event's already been grouped and stored, never inline in the ingestion request. A slow or unreachable Slack webhook, a bounced email, a stalled call, none of that ever adds latency to the request your app made to report the error in the first place.
What actually lands in an inbox when a rule fires.