Skip to main content
The Communications module sends incident updates directly to the people who need them — by email, SMS, or Slack — rather than broadcasting to everyone. Responders pick a prepared template, the incident’s details fill themselves in, and the message reaches only the stakeholder groups whose conditions the incident matches. It is the targeted counterpart to a status page. A status page tells anyone who looks; Communications tells a specific audience, and can require review before anything goes out.
Communications is enabled per organization. If the Communications tab does not appear on your incidents, contact your account team.

​
Where to Start

Sending a Communication

The responder flow: pick a template and stage, edit it, send it for review, and send it.

Recipient Groups

Define who hears about what, and the conditions that decide when they do.

Templates and Stages

Prepare the messages in advance, one per stage of an incident.

Communication Sources

The addresses and numbers your messages come from, and getting them allowlisted.

​
The Moving Parts

Four pieces fit together. Set them up in this order — each depends on the one before it:
1

Types

A category of communication, such as customer updates or internal leadership updates. Everything else hangs off a type: groups belong to one, and so do templates.
2

Stages

The phases of an incident you communicate at — for example initial, investigating, resolved. Stages are shared across the organization.
3

Templates

The prepared message for a type, with separate content per stage and per channel. Liquid variables pull in the incident’s own details.
4

Groups

Who receives a type of communication, and under what conditions — a severity, a service, a functionality, a team, or an incident type.
With those in place, sending during an incident is a matter of choosing a template and a stage, checking the text, and sending.

​
What a Responder Does

During an incident, the Communications tab lists everything already sent, with its delivery status, and lets you create the next update. The same flow is available in Slack with /rootly comms new. Rootly suggests the template that fits the incident, and the recipients are worked out from the groups whose conditions the incident matches — so a responder is choosing what to say, not who to say it to.
The decision about who hears about an incident belongs in your group conditions, made calmly in advance. Leaving it to the person writing an update at 3am is how the wrong stakeholders get paged, or the right ones get missed.

​
Review Before Sending

Any draft can be shared to a Slack channel for review before it goes out. The request is clearly marked as needing review, so approval happens where your team already works rather than in a separate tool.
A sent communication cannot be recalled. For anything customer-facing, or anything a regulator or executive will read, route it through review — and remember that SMS in particular has no correction path once delivered.

​
Best Practices

  • Decide your audiences before your messages. Groups and their conditions are the hard part; templates are easy once you know who is listening.
  • Write one template per type, not per incident. Stages handle the difference between “we’re investigating” and “it’s resolved”.
  • Use Liquid for anything factual. Severity, title, summary, and timestamps should come from the incident record rather than being retyped under pressure.
  • Make review the default for external audiences. Internal updates can go direct; customer-facing ones benefit from a second reader.
  • Allowlist Rootly’s sending addresses and numbers early. Discovering a spam filter mid-incident is an avoidable failure — see Communication Sources.
  • Revisit conditions after reorganizations. Groups scoped to services or teams drift when ownership changes.

Status Pages

Broadcast status publicly, for anyone who looks.

Publishing Incidents

Post incident updates to a status page.

Liquid Variables

Every incident value a template can pull in.

Workflows

Automate notifications that do not need a human author.

​
Frequently Asked Questions

Reach and intent. A status page is public and passive — anyone can look, nobody is notified. Communications is targeted and active: it pushes a message by email, SMS, or Slack to defined groups. Most teams use both, with the status page as the public record and Communications for the audiences who need telling directly.
A workflow fires automatically with no author, which suits mechanical notifications. A communication is written or approved by a person, so it suits messages where the wording matters and someone should be accountable for it.
Yes. Groups can contain external members, which is the point — customers, executives, and support leads generally are not Rootly users.
Yes. Types, stages, templates, and groups all have Terraform resources. See Terraform.