How to Write Service Status Updates

Status Update Header

By David Mytton,
CEO & Founder of Server Density.

Published on the 26th May, 2016.

The lowly incident status update happens to be one of the most essential pieces of communication a company gets to write.

When users navigate to a status page, they’re driven by a heightened sense of urgency (compared to, say, a website, a blog, or a newsletter). Not many words get as dissected, discussed and forwarded as the ones we place on our status page.

Now let’s state the obvious. Customers couldn’t care less about a string of words posted on a status update. What they care about is, “am I in good hands?” Every time we publish (or fail to publish) a service status update we are ultimately answering that question.

So how do you go about writing status updates that send the right message to customers?

Status Update

1. Write frequent status updates

First and foremost, good status updates are frequent.

Some companies send them as often as every 20 minutes. Whatever frequency you decide upon, make sure you set accurate expectations. If you intend to spread your status updates over longer intervals, let users know in advance. Never leave them hanging, wondering, not knowing what’s going on. That is not a great customer journey.

2. Well written status updates

You don’t need to have “a voice” in order to write great status updates. You just need to be authoritative. What does authoritative mean?

To start with, authoritative means honest. An honest service update is, by definition, fearless. Nothing betrays fear like ten dollar weasel phrases (“we apologise that our provider . . .”) or passive wording that shirks responsibility (“it was decided that . . .”). Authoritative writing does the opposite. It embraces responsibility, and opens up to all the learnings it bestows.

“Express that opinion clearly, gracefully and empathetically.”

Caroline Goyder, Gravitas

Well written status updates are brief and deceptively simple. Deceptively because it’s not that easy. To make your status updates simple for your users, you need to break complex concepts down to just a few key words. Before you start editing your words, you need to edit your thinking. Pick the essential from the inessential. You can’t write a good service status update until you’re clear about what you know and what you don’t.

3. Productive

What we learned early on was that regular and well-written status updates reduce the amount of incoming support requests. Investing the time to get incident updates right was paying productivity dividends for the rest of the team.

Back in 2009, David, our CEO, was the only one waking up in the middle of the night to save a server. And he was also the one publishing service updates on the Server Density blog, which served as a makeshift status update repository.

Eventually we transitioned to a dedicated status page, hosted by a 3rd party, separate from our systems. As the team grew, the responsibility for status updates now sits with the engineer on call, and with our support folks too. The one thing that hasn’t changed though, is how we write those status updates.

We only state the facts. We avoid flimsy assumptions (“we think”), tacky remorse (“we apologize”), useless adverbs (“currently”) and generic drivel (“in the process of”). If we have no clue what’s going on, we don’t pretend otherwise. If there is something we do know—what services are operational, for example—we make sure we mention them.

The primary goal of our status updates is to be there for our customers (#1: frequent) and also indicate that they’re in good hands (#2: well written).

The vast majority of our users are technically savvy. They want to have as much detail about the outage as possible, so they can make their own assessments. By including specific and relevant facts in the status update, we satisfy that need and reduce incoming service requests too.

Authoring those regular, one-sentence-long text bites, is a great way to keep customers and team members in the loop.

By the way, if we cannot summarise everything in a single sentence, chances are we don’t know what we’re doing, and probably have no plan of action. The rigour involved in describing the problem in a few short words helps us inch closer to resolution.

Summary

When faced with service interruptions, we drop everything in our hands and perform operational backflips 24×7 until the service is restored for all customers.

During this time, over-communication is a good thing. As is transparency, i.e. acknowledging problems and throwing the public light of accountability on all remaining issues until they’re resolved.

While the crisis is unfolding we publish short status updates at regular intervals. We stick to the facts, including scope of impact and possible workarounds. We update the status page even if it’s just to say “we’re still looking into it.”

Incident Status Update 2

Once service is resolved, it’s time to turn our focus on the less urgent, but equally important piece of writing: the postmortem. Communicating detailed postmortems helps restore our credibility with our users. It demonstrates that someone is investing time on their product. That they care enough to sit down and think things through. Most crucially, it also creates the space for our team to learn and grow as a company.

What about you? How do you handle service status updates, where do you host them, and who is accountable for it?

Free eBook: 4 Steps to Successful DevOps

This eBook will show you how we i) hacked our on-call rotation to increase code resilience, ii) broke our infrastructure, on purpose, to debug quicker and increase uptime, and iii) borrowed practices from the healthcare and aviation industry, to reduce complexity, stress and fatigue. And speaking of stress and fatigue, we’ve devoted an entire chapter on how we placed humans at the centre of Ops, in order to increase their productivity and boost the uptime of the systems they manage. What are you waiting for, download your free copy now.

Help us speak your language. What is your primary tech stack?

What infrastructure do you currently work with?

Articles you care about. Delivered.

Help us speak your language. What is your primary tech stack?

Maybe another time