reference
Integrations
An alert has to arrive somewhere. That “somewhere” is split into two ideas, and keeping them apart is what lets one Slack workspace serve fifty monitors without fifty pieces of configuration.
Channels and routes
Section titled “Channels and routes”A channel is a configured destination — “Production Slack” pointing at one specific webhook URL, or “on-call inbox” pointing at one address. You create it once, in workspace settings, and it holds the credential.
A route says which events reach that channel, and for what. Routes are what you attach to monitors; channels are what routes point at.
The practical consequence: rotating a Slack webhook URL is one edit to one channel, not an edit to every monitor that uses it.
Available channels
Section titled “Available channels”| Channel | Notes |
|---|---|
| Any address. Must be verified before it receives alerts — see below. | |
| Slack | An incoming webhook URL for one channel. |
Every workspace starts with a route to the owner’s email address, so a monitor created five minutes after signup already has somewhere to alert.
Events
Section titled “Events”A route subscribes to one or more of four events:
| Event | Fires when |
|---|---|
down |
A monitor passed its grace deadline. |
recovery |
A monitor that was down checked in again. |
slow |
A run finished, but took long enough to be worth flagging. |
escalation |
A monitor has stayed down and the escalation schedule fired again. |
Subscribing to down without recovery is a common mistake. You get told the
job broke and never told it came back, so the only way to find out is to go and
look — which is the habit the product exists to remove.
Environments
Section titled “Environments”An environment is a label a monitor belongs to — production, staging,
internal. Monitors carry one, and routes can target it.
The reason it exists is that alerting rules are almost never per-job; they’re per-tier. “Production wakes the on-call, staging goes to a Slack channel nobody gets paged by” is one rule about two environments, not a rule repeated across sixty monitors. Move a job from staging to production and its alerting follows, because the routing was never attached to the job in the first place.
This is also the cleanest way to give one noisy job different treatment: put it in its own environment rather than hanging a special-case route off the monitor.
Routing is additive
Section titled “Routing is additive”Routes can be attached at three scopes:
- Per monitor — this job alerts here.
- Per environment — everything in staging alerts here.
- Workspace-wide — everything alerts here.
These combine; they do not override. A monitor’s alerts go to the union of its own routes, its environment’s routes, and the workspace-wide routes.
This is worth internalising because the intuition usually runs the other way. Adding a per-monitor route to a noisy job does not stop the workspace-wide route from also firing — you’ll get both. If you want one job to go somewhere else instead, the workspace-wide route is the one to narrow, or the monitor is the one to move to its own environment.
The upside of the union model is that it fails safe. A misconfigured per-monitor route can’t silently detach a job from the alerting everything else gets.
Email verification
Section titled “Email verification”An email channel doesn’t receive anything until the address is confirmed with a code sent to it. Until then the channel exists, shows as unverified, and is skipped when alerts are dispatched.
This is deliberate, and it’s about the failure mode of a typo. An unverified address that silently accepted alerts would look configured, sit in the list next to the working ones, and send every page into nowhere — and you’d find out during the incident it was supposed to catch.
Testing a channel
Section titled “Testing a channel”Every channel can send a test message. Use it after creating one, and again after rotating a credential.
Test results are per channel, not a single pass/fail: if you test several and one fails, you’re told which one. A green “sent” that quietly covered a failed delivery would defeat the purpose of testing at all.
Disabling
Section titled “Disabling”A channel can be disabled without being deleted. Its routes stay attached and stop delivering, which is the right tool when a Slack workspace is being migrated and you want the configuration to survive.
Deleting a channel removes its routes with it.