Skip to main content
During an incident, the Communications tab is where updates to stakeholders are written, reviewed, and sent. Everything already sent is listed there with its delivery status, so a responder joining late can see what has gone out before adding to it.
The same flow is available in Slack with /rootly comms new, which matters when the incident is being run in a channel rather than in the web interface.

​
Reviewing What Has Already Gone Out

Before writing anything, check the record. The Completed list shows each communication that has been sent, and opening one shows:
  • Where it originated
  • Which recipient groups received it, including any Slack channels
  • Its delivery state — sent, partially sent, or still sending
  • Any drafts associated with it
Read the last update before writing the next one. Stakeholder trust is lost faster by contradicting a previous message than by saying nothing, and the previous message is rarely the one you remember sending.

​
Creating an Update

1

Start a new communication

Select Create New in the incident’s Communications tab, or run /rootly comms new in Slack.
2

Pick the template

Rootly suggests the template that fits the incident. Every available template is in the dropdown if the suggestion is not the right one.
3

Pick the stage

Stages represent where the incident has reached — an initial notification reads differently from a resolution notice. Selecting a stage loads that stage’s prepared content. See Templates and Stages.
4

Create

This opens the editor with the template rendered against the live incident.

​
The Editor

The editor shows the message alongside the facts about it. On the left, the details of the communication itself: its status, the type and template it came from, the stage, who created it, the addresses and numbers it will send from, and the recipient groups it will reach. On the right, the message. Template content arrives already filled in — Liquid variables have pulled the incident’s title, summary, severity, and timestamps out of the record rather than asking you to retype them. Each channel is edited separately, so the email body, the SMS text, and the Slack message can each say what suits that medium. Editing here changes this message only; the template is untouched.
SMS is capped near 160 characters, so the SMS version of an update is not a shortened email — it is a different message. Write it as a pointer: what is wrong, who is affected, and where to read more.

​
Sending, Saving, or Requesting Review

Three actions, and choosing between them is mostly about audience:
​
immediate
Deliver now, to every group whose conditions the incident matches. Requires permission to send. There is no recall.
​
hold
Keep the message without sending. Useful when you have written an update ahead of a decision that has not been made yet, or when handing the incident to the next responder.
​
review
Send the draft to a Slack channel or specific people for review. The request is clearly marked as needing review, so approvers see it as a task rather than another notification.

​
Getting a Communication Reviewed

Review exists because the cost of a wrong external message is much higher than the cost of a delayed one.
1

Share the draft for preview

Choose the channel or people who should read it. They see the message as recipients will.
2

Collect feedback in the channel

Discussion happens in Slack, next to the incident, rather than in a separate approval tool.
3

Revise and send

Apply any changes in the editor, then send. The draft and the sent message both stay on the record.
Review is worth its delay for anything customer-facing, anything a regulator or executive will read, and any message stating a cause or a restoration time. Internal “we are on it” updates rarely need it.

​
Delivery

Once sent, a communication moves through delivery rather than completing instantly. The Communications tab shows whether it is still sending, fully sent, or only partially delivered. Partial delivery usually means individual recipients failed rather than the message failing — a bounced address, an unreachable number. Check the affected recipients rather than resending to everyone, which would deliver the message twice to people who already have it.

​
Troubleshooting

Recipients come from group conditions, not from the message. If no group’s conditions match this incident, there is nobody to send to. Check the incident’s severity, service, functionality, team, and type against your group conditions.
A group’s conditions are broader than intended. Conditions can require all criteria to match or any of them — a group set to “any” reaches far more incidents than one set to “all”.
Almost always filtering rather than delivery. Confirm Rootly’s sending addresses are allowlisted — see Communication Sources — and check whether the recipient’s provider quarantined it.
A Liquid variable that does not resolve renders empty. Usually the field is genuinely blank on the incident — a summary that was never written, for instance. Fill it on the incident and recreate the communication.
Sending is permission-gated. Save the draft and share it for preview so someone with permission can send it.

Recipient Groups

Why a given incident reaches a given audience.

Templates and Stages

Prepare the messages this flow draws on.