"We are aware that payments are failing for some accounts. We are working on it. Next update at 10:30."
That is a complete incident update. It has three sentences, and the last one tells the customer when to look again.
Incident communication is what you tell the people who depend on your service while it is broken, and when they will hear from you next. This article looks at it from the support queue, where customers' questions arrive while the fault is still being found.
Incident communication starts in the support queue
Customers do not see your monitoring. They see an error, and some of them write to support.
Atlassian's guide to incident communication lists the groups an incident update has to reach. One of them is the front-line support team: "those who will be directly answering questions and giving customers updates during the incident."
That makes the first line, the team that answers tickets first, two things at once. It is an audience: it needs the facts before the customers do, or it answers from guesses. And it is a channel: every reply it sends during an incident is an incident update, whether anyone planned it or not.
In customer support for business clients, one fault arrives as tickets from many accounts at once. Our article on B2B customer support covers how to link those tickets to one incident. This one is about what you send back.
The first update goes out before you know the cause
PagerDuty's status page guide puts the first update within 10 to 15 minutes of detection. The first update does not need the cause. Atlassian's guide lists what it should do instead: acknowledge the issue, briefly summarize the known impact, promise further updates and, if you are able, address concerns about security or data loss.
Impact means what the customer sees, in the customer's words. "Payments to some accounts are failing" is impact. The name of the server that stopped is not.
If there is a way to keep working while the fault is fixed, it goes in as early as possible. PagerDuty's guide says it plainly: if a temporary workaround exists, share it immediately.
A first update, written in advance:
We are aware that [what the customer sees] for [which accounts or features]. We are working on it. [Workaround, if there is one.] Next update at [time].
Every update says when the next one comes
Atlassian's guide also asks this of every update: "always indicate when to expect the next update." PagerDuty's guide gives the reason. A timestamp for the next update, it says, reduces customer anxiety and the need for them to contact your support team.
How often? Atlassian's Statuspage tips say every 30 minutes, or whatever cadence fits the situation. PagerDuty's guide calls an update every 30 minutes a good baseline for major outages. Atlassian's guide sets the outer limit: while the issue still affects customers' ability to use the product, never more than one hour without an update.
The rule that holds the schedule together is the dull one. When the next update is due and there is no news, the update goes out anyway. Atlassian's guide says even "We're still working on the problem, nothing new to report" is better than saying nothing. A promised time that passes in silence tells the customer the promise was not real.
| Update | When it goes out | What it says |
|---|---|---|
| The first one | Within 10 to 15 minutes of detection (PagerDuty) | What the customer sees, that the team is on it, a workaround if there is one, the time of the next update |
| Every one after it | Every 30 minutes, or the cadence that fits (Atlassian Statuspage; PagerDuty for major outages); never more than one hour while the issue affects customers' ability to use the product (Atlassian guide) | What changed, or that nothing has, and the time of the next update |
| The last one | When the service works again | That it works, what was done in a sentence or two, and the review that follows |
One page, and every reply points to it
During an incident the same question arrives through the ticket queue, chat, email and the account manager's phone. Atlassian's guide recommends that you identify one primary communication vehicle and funnel everyone there from the other channels. Atlassian's Statuspage tips add a separate rule: stay consistent across channels.
For the first line, this means the answer to an outage ticket is short. What we know, the link to the page with the updates, the time of the next update. When that page changes, the reply changes with it, before the next ticket is answered.
Atlassian's guide recommends a dedicated status page as that primary channel. If you do not have one yet, an email to the affected accounts or a notice in your client portal can do the job. What matters is that there is one, and that the first line knows which one it is.
The person writing the updates is not the person fixing the fault
Google's Site Reliability Engineering book says several distinct roles should be delegated to particular individuals during an incident. One of them is communication. The person in that role is "the public face of the incident response task force", and the duties include issuing periodic updates to the incident response team and stakeholders. The work on the system itself belongs to a different role.
The engineer fixing the fault has no attention left for wording. So one named person writes, someone on the incident feeds that person the facts, and the first line gets each update before it is sent to customers.
The last update closes the incident and promises the review
PagerDuty's guide describes the final update: once service is restored, confirm that all systems are stable, briefly explain what was done to fix the issue, and commit to a follow-up post-incident review to help prevent recurrence.
Then keep the promise, and send the review to the accounts that were affected. A fault that keeps coming back needs more than another update. Our article on recurring incidents covers the problem record: one entry that links every repeat ticket to its cause.
When an outside team answers your customers
If your first line is outsourced, the outside team sees the tickets first and learns the facts only from you. Atlassian's guide recommends that you decide on the common language ahead of time (the wording your updates will use), get it approved by your managers and save it in a template. With an outside team, that advice becomes the agreement. Settle four things before the first incident:
- Who declares an incident. A named person on your side, reachable at any hour, who confirms that a series of tickets is one incident.
- What the outside team may send without asking. The approved first update: the issue is known, it is being worked on, the time of the next update.
- Who writes the updates after that. One person on your side owns the wording. The outside team sends it to every affected ticket.
- Where the team gets the facts. One channel the outside team watches, so the first line hears about a change before your customers do.
How IMMIDO fits
We run 24/7 first-line support inside your own tools, as a fixed monthly team, not per ticket. Spribe is one client whose work with us is published as a case study. There, requests and incidents are managed in Jira and Slack, and under the response-time commitment the client set, the first response to each request is due within 15 minutes. How we run the first line is described on our technical support page.
If your first line does not yet know what to say during an outage, settle it before the next one. Book a call and we will go through the four points above with you.
Sources: Atlassian, Incident communication best practices (the front-line support team, first contact, the next update, one hour, one primary channel, nothing new to report, common language ahead of time) · Atlassian Statuspage, Incident communication tips (every 30 minutes, consistent across channels) · PagerDuty, Status page guide (10 to 15 minutes, 30 minutes for major outages, the next-update timestamp, the workaround, the final update) · Google, Site Reliability Engineering, Managing Incidents (distinct roles, the communication role) · IMMIDO, Spribe case study.