Named channels,and a default that catches everything else.

Channels are named things

A channel is a destination you create once and give a name: an email address, a phone number, a Slack webhook, or your own webhook endpoint. You configure them on the Notifications page, and the same channel can serve any number of services.

SMS is the only channel a plan gates. On Free, an SMS channel is simply left out of the set an alert resolves to — it is not an error, and nothing else routed to that service is affected.

SMS also asks you to confirm that the person holding the number agrees to receive Beaam texts, and records the sentence you agreed to. You are asked again if the number changes or the channel is re-enabled, and not asked for a rename or a routing change — being re-prompted for nothing is how people learn to click past a consent step.

The default set, and when routing overrides it

Mark one or more channels as default. Anything without more specific instructions goes there — which, for most people, is everything, and is the whole configuration.

A service can override that. Point a service at specific channels and those channels are used instead of the default set, not in addition to it. Point it at nothing and it inherits the default set — inheritance is the absence of a rule, so there is no "reset to default" to remember: removing the routing is the reset.

That gives three states worth naming, because the middle one is the one people get wrong: a service with no routing uses your defaults; a service with routing uses exactly those channels; and a channel that is not default and not routed anywhere never fires at all. A channel can be created, enabled, correct, and still be selected by nothing.

The exception for something broken

One case ignores your routing on purpose. When an incident isbroken — the service is down, not merely degraded — the alert goes to your default channels as well as whatever routing selected, deduplicated so no channel gets it twice.

The reason is that routing is usually narrowed for quiet, and quiet is exactly the wrong outcome for the one alert that matters. A service routed to a Slack channel you read on Tuesdays still reaches you by every default channel you have when it actually goes down.

After the send

Delivery is a ledger, not a fire-and-forget. Every send writes a row carrying which channel it used, what it said, how many attempts it has taken and where it currently stands — so an alert that did not arrive is a state you can look at rather than an absence you have to infer.

A failed send is retried with exponential backoff: one minute, then doubling, capped at fifteen minutes between attempts, up tosix attempts in total. That is what turns a provider blip into a delivered alert instead of a missed one. Beyond six it stops and says so, because a retry loop that never ends is its own kind of silence.

Cooldown, so one bad hour is not fifty messages

After an alert fires for a service, further alerts for that service are suppressed for 30 minutes — even if a new incident opens inside that window. A service restarting through a bad deploy is one message, not twenty.

Suppressed alerts are recorded as skipped with the cooldown named, so the history shows what Beaam decided rather than leaving a gap you have to interpret. The cooldown is per service, so an unrelated service breaking in the same half hour still reaches you.

Proving the path before you need it

Send a test alert from the app. It goes through the real senders to the real channel and writes a real ledger row — it does not simulate anything, so a test that arrives is proof the path works end to end. This is worth doing on the day you set Beaam up, not the day you first need it.

Questions