Skip to main content

Notification channels and routing

Two layers decide who hears about an incident. Each person owns their channels and their own floors and quiet hours in My account. The workspace owns the routing: which roles hear which severity, plus team-level destinations such as a Slack channel or Jira. Both fail open: when nobody would be told, everybody is.

Personal channels​

My account, Notifications.

  • Telegram: open the bot link, send it anything, paste back the ID it answers with. Incident messages arrive with inline Ack and Resolve buttons that act directly and rewrite the message, so the whole chat sees it is handled and by whom.
  • Browser push: "enable on this device" asks the browser's permission and registers that browser. Push is per device: every registered browser gets real alerts, the row shows which device a subscription belongs to, and Test reaches only the browser you click it in. The notification carries the incident text itself and two buttons, Ack and Resolve, that act without opening anything; a click on the body opens the incident in its workspace, reusing a console tab you already have open. The row also tells the truth per device: when the last delivery was, and whether the device has shown it. A subscription the browser's push service reports as gone is retired by itself, so a browser you reinstalled does not linger as a dead row.
  • E-mail: verified at registration, works without setup. Alert e-mails carry take on and resolve buttons: signed links bound to you, valid for 24 hours. Opening the link shows a confirmation page with the incident number and a button (mail scanners open links, so nothing happens on the open alone); the button acts, and the timeline records that it came from e-mail. A forwarded mail acts in the name of the original recipient, which is why the links expire.
  • Webhook: a URL of yours that receives the incident as JSON, signed with a per-user secret shown next to the row, so your receiver can verify the sender. See Webhooks for the payload and the signature check.

Each channel has its own on/off switch, a severity floor (do not send me warnings here) and quiet hours in your time zone. Two things never yield to those settings: critical incidents, and escalation steps. Warnings can be muted entirely per person. Critical incidents also reach every member who has an e-mail address, whether or not they ever set up a channel, unless that person switched e-mail off explicitly.

Personal ladder​

Instead of hearing about a critical incident on every channel at once, each member can arrange their channels as a ladder in My account, Notifications: up to three steps, the first one immediately, the next ones after a delay you pick (1, 2, 5, 10, 15 or 30 minutes), each channel used once. "Telegram now, push after 5 minutes, e-mail after 15" is the typical shape. The card reads the ladder back to you as one sentence.

What the ladder does and does not do:

  • It applies to critical incidents only. Warnings keep the plain per-channel settings.
  • Any acknowledgement by any member stops it; the later steps are never sent for an incident someone already took on.
  • A step whose channel cannot reach you right now (Telegram not linked, no push device) is skipped and the next one fires instead.
  • A step that comes due far too late (more than ten minutes after its time, for example after a long platform outage) is not sent; stale noise helps nobody.
  • Phone calls are not a ladder step. Calls belong to the workspace's escalation, not to personal preferences.

Workspace routing​

Alerting, Delivery and on-call. The routing matrix maps severities to roles: who hears about critical, who about warnings. Owners are always included. If a severity matches nobody, or the matched people have no working channel, the whole workspace is notified, never nobody.

Team-level destinations live one tab over, in Integrations: a Slack channel with a two-way /wakora command, a Microsoft Teams channel with cards, and Jira issues created from an incident or automatically for every critical one.

Digests, not storms​

Notifications are batched per workspace. When several incidents open within seconds (a host loses power and thirty sites go with it), you receive one digest listing them rather than thirty messages. The batch waits for the burst to settle for about half a minute, with a hard cap of a minute and a half so the first notice is never late. Reopens of an incident that just resolved are folded into the same digest, and a flapping incident is re-notified at most once every 30 minutes.

Every message, on every channel, carries the runbook attached to the rule when one exists, so the instruction arrives with the alert.

Phone calls​

Critical incidents can ring a phone through the escalation ladder. Calls go only to verified numbers, and the verified number is the consent: add yours in My account, Profile, confirm the four-digit code the verification call speaks, and remove the number when you no longer want to be called. The Call row among your channels shows the state and nothing else; how the ladder places calls, in chains and waves with two calls per person, is in Escalation and on-call.

  • Incidents: what a notification is about, and what acknowledging does
  • Runbooks: the instruction that rides with the alert
  • Integrations: Slack, Teams, Jira, team webhook
  • My account: channels, quiet hours, the personal ladder