Incident communication best practices

Key takeaways: Incident communication is the process of telling customers, employees, and stakeholders that a service is degraded or down, what’s being done about it, and when to expect the next update — from first acknowledgment through resolution and postmortem.

• What it is: A pre-planned set of channels (status page, email, chat, SMS, social), audiences, message templates, and update cadence that the team follows the moment an incident is declared.

• Why it matters: Silence during downtime costs more trust than the outage itself; customers who are kept informed react far less negatively and are less likely to leave.

• How Jira Service Management helps: Manages incidents and their communications from one place, syncs updates to Slack and Microsoft Teams, surfaces announcements on the portal, and connects to Statuspage for customer-facing updates.

Incident communication is the process of telling the people who depend on a service — customers, employees, and internal stakeholders — that it’s experiencing an outage or degraded performance, what the team is doing about it, and when to expect the next update. For web and software services where 24/7 availability is assumed, it’s as much a part of incident response as the fix itself.

It’s more involved than a bulk email. Different audiences need different messages on different channels, with different expectations for how often they hear from you. Since some downtime is inevitable, the work is in preparing before an incident, not improvising during one.

In this guide to incident communication best practices. We’ll cover:

• Why incident communication is important

• How to prep for incident communication

• How incident communication pros handle the task

• Why incident communication doesn’t end after the incident

Why incident communication matters

Your customers care. Your colleagues care. You should care. Poorly handled downtime can be a really bad experience for your customers and your teams, which can affect your bottom line. You’ll lose future customers due to a lack of trust. Team morale can suffer, leading to lower productivity.

Luckily, unplanned downtime doesn’t have to turn into a customer service nightmare. It turns out that if you just keep your customers in the loop by communicating what’s happening and what you’re doing to fix the problem, they’ll understand and have a much less negative reaction to the whole situation.

Prepping for incident communication

Proper preparation prevents poor performance. If it’s a good enough slogan for going into battle, it’s good enough for your incident communication strategy. When you’re in the heat of an incident, you’ll thank yourself for putting time into incident communication.

Define what you consider an incident

Before we can communicate incidents, we need to decide what constitutes an incident. Many web companies rely on a standardized 4-tier severity definition system. Here’s a great guide on severity definitions from our own incident handbook.

Whatever your thresholds for incident severity are, it’s important to draw a clear line in the sand (ideally around a measurable metric). If you designate an incident at Sev 1, it’s important for anyone on your team to be able to know exactly what that means.

A severity system is also helpful to eliminate the inherent shades of grey that come with downtime.

No matter what system you settle on, we recommend a zero-tolerance communication plan for any incidents involving security issues or data loss.

Pick your communication solutions, channels, and message templates ahead of time

Professional support teams and site reliability engineers don’t decide on the fly what channels to communicate over. They make a plan in advance.

There are five main communication channels for incident communication:

• A dedicated status page

• Embedded status

• Email

• Workplace chat tool

• Social media

• SMS

Dedicated status page

We recommend teams use a dedicated status page as their primary incident communication solution. Whether you build it yourself or use a hosted solution like Statuspage, it’s important to provide your customers and colleagues with a clear source of truth during an incident. Statuspage also gives your users the option to subscribe to receive updates as soon as they’re posted. This takes the support burden off teams who should be heads-down fixing the problem.

Embedded status

Statuspage also makes it easy to embed status information directly onto any website that customers operate. We know most visitors are likely to check a provider’s home page or support page before looking for a status page. The embedded widget (here's an example) is an easy way to let visitors know if an incident is underway. Visitors can also click through on the widget to get to the status page.

Email

You can give your audience the option to subscribe to email updates using a product like Statuspage. Whether you’re sending directly from your email tool, or using a status page to trigger email sends, email a reliable channel for incident communication.

Chat tools

Reduce context switching and information gaps for employees and agents with Jira Service Management chat. Jira Service Management chat will sync conversations in Slack or Microsoft Teams with your tickets. Seamless conversation between popular chat tools and support helps to provide robust context to a problem, leading to a fast resolution.

Social media

Many teams use social channels like Twitter to communicate during an incident. It’s good to use this as part of your strategy, but don't rely on it as your only means of communication.

SMS

Receiving an SMS message, or text message, is often a more immediate way to reach someone and a preferred method for many people when it comes to critical inbound alerts, such as a downtime announcement. It’s also a channel where people can become message-fatigued very quickly and will unsubscribe if they see too many messages that aren’t relevant to them.

None of these channels is a silver bullet for incident comms. They all have different strengths, and the real power comes when you layer them together. For example, at Atlassian, we post incidents to a status page but also push those updates to Twitter. An announcement about the incident is also visible on our Jira Service Management portal. These messages then direct the user back to the status page for more details on the incident. Managing incidents in Jira Service Management allows for multiple points of communication without getting wires crossed or losing your customers' trust in translation.

Tailor alerts and communications to the right audience

When an incident arises, you need to know who to communicate to, how to reach them, and how to do it with the least friction and fewest resources possible in order to avoid a customer service nightmare and/or communication meltdown. It’s best to start internally with an immediate response team and work outward, curating messages for the appropriate audience.

While every organization is different, in general, it helps to think of these audiences as 5 distinct groups that need to be communicated with:

1. Core on-call team: The first to know something is wrong, almost immediately upon impact (usually from monitoring and alerting tools). Internal teams work behind the scenes to detect, swarm, contextualize, and resolve incidents with collaborative communication tools.

2. Front-line support team: Those who will be directly answering questions and giving customers updates during the incident. It’s an incredibly important role, so this team must get the right information to pass along to end users.

3. Managers and executive team: The core team needs to communicate with this group so they know what’s going on, the potential impact on the following two groups, and hopefully an estimate of how long it could last.

4. General employee population: Employees need to be kept informed as services they rely on go down and up. Proactively communicating with these users means less “what’s the status of this” questions, fewer duplicate IT support tickets, and more focus to fix the problem at hand.

5. External customers: If the incident affects external customers some communication must be sent out to explain the problem and when they can expect a fix – or at least an update every nth amount of time. For issues that are still currently affecting your customers’ ability to use your product, we recommend never going more than one hour without sending an update. You should also always indicate when to expect the next update. If it is a severe enough incident – especially one involving security or data loss – you will definitely want to expedite external comms and pull in the necessary other teams (legal, HR, security, etc.)

Set up templates for incident and outage communication

In the heat of an incident, the last thing you want to worry about is how to wordsmith an incident announcement. Wording the incident the wrong way is a perfect target for non-technical managers who might be looking for any reason to criticize your team’s response process.

Decide on the common language ahead of time, get it approved by your managers, and save it in a template. This makes it easy to plug in the relevant details and fire off an incident the day of.

Here are two of the incident templates we use for our own status page:

• The site is currently experiencing a higher than normal amount of load, and may be causing pages to be slow or unresponsive. We’re investigating the cause and will provide an update as soon as possible.

• Our storage provider for public metrics data is currently experiencing infrastructure issues. Updates will be made available as the situation develops or information is provided to us.

Managing communication during an incident

The lifecycle of an incident will likely include several points of contact. Done well, there’s a familiar three-act structure to an incident: First contact, updates during the incident, resolution, and post-mortem.

Prologue: Centralized internal team communication

 Before anything else, internal teams on the back end of an incident should have an established communication platform and be ready to swarm when an issue arises.

Centralizing and filtering alerts across monitoring, logging, and CI/CD tools ensures a fast response from your team. With a platform like Jira Service Management, teams can quickly swarm an incident, gain context, and stay in touch throughout its duration.

Part 1: First contact

The initial update is the most important. Everything from what you say to how and when you say it sets the tone for how your response will be perceived. This is where it really helps to have a template set up in advance.

Your goal should be to quickly acknowledge the issue, briefly summarize the known impact, promise further updates, and, if you’re able, alleviate any concerns about security or data loss. It's important to acknowledge there's an issue, even if you don't know the exact details yet.

Part 2: Regular updates during the incident

Mid-incident communication is critical.

The SRE teams at Google list Communication Lead as one of the key roles someone should oversee during an incident.

From Google’s book “Site Reliability Engineering” on the role of the communication lead:

This person is the public face of the incident response task force. Their duties most definitely include issuing periodic updates to the incident response team and stakeholders (usually via email), and may extend to tasks such as keeping the incident document accurate and up to date.”

This person will also be in charge of continuing to update the status page or posting updates to other channels as the situation evolves. Even an update saying “We’re still working on the problem, nothing new to report,” is better than saying nothing and leaving your audience hanging. People left in the dark start to expect the worst.

Communication with affected users and other stakeholders is imperative. Use your pre-determined channel(s) to tell users what’s going on. On a homepage, this may be a Statuspage alert to help customers see that your team is aware of the problem and save agents time from dealing with redundancy. Keep customers in the loop by using multiple notification channels, including SMS, email, and mobile push notifications. 

Whatever tool you choose to use, we recommend that you identify one as your primary communication vehicle and funnel everyone there from the other channels. Managing incident communications through Jira Service Management ensures the right messages get to the right people.

Part 3: Resolution, post-mortem, what comes next

In 2010, Facebook suffered a 2.5-hour outage affecting what was then half a billion users. When it was over, a Facebook engineer posted a 395-word summary to the company’s engineering blog about the incident.

From the blog:

Early today Facebook was down or unreachable for many of you for approximately 2.5 hours. This is the worst outage we’ve had in over four years, and we wanted to first of all apologize for it. We also wanted to provide much more technical detail on what happened and share one big lesson learned.

The outline of the post-mortem is simple:

• Acknowledge the problem, empathize with those affected, and apologize

• Explain what went wrong and why

• Explain what was done to fix the incident and what was done to prevent repeat incidents

• Acknowledge, empathize, and apologize once again

There’s no need for flowery language or grandiose claims in communication like this. Keep it simple and direct. For example, from the Facebook blog:

We apologize again for the site outage, and we want you to know that we take the performance and reliability of Facebook very seriously.

Language like this makes it easy for your customers and colleagues to trust that you’re running a level-headed team and keeping your eye on the ball. Browse our own incident response postmortem template for more ideas.

The reality of running always-on services is that sometimes, things unexpectedly break. Effectively communicating during downtime can actually build trust with both colleagues and customers. Responding well can make all the difference. We've also created this simple tool to help you to quickly write effective communications during incidents.