Status Updates, Emails and Reports

Writing for busy readers

The people you write to at work are reading between other things. A manager sees your email in a list of fifty, on a phone, between two meetings. A contact-center agent glances at an incident update while a customer is on the line. Neither reads your message from top to bottom; they read the subject, the first lines, and decide whether to continue.

That is not a character flaw to fight against. It is the situation to write for. Before you write anything, answer three questions:

1. Who reads this? An engineer, a manager, a user and a customer need different words and different details.
2. What should they know or do afterward? If you cannot say it in one sentence, you are not ready to write yet.
3. Is this the right channel? A quick question fits chat. A decision that must be found later belongs in email or a ticket. Bad news for one person is often better said in a call first and confirmed in writing.

Bottom line up front

Bottom line up front (BLUF) means opening a message with its conclusion, decision or request, and putting the background and supporting details after it. The term is usually traced to US Army writing guidance (Army Regulation 25-50, on preparing correspondence), but it works for any reader who is short of time.

Most people write in the order they experienced things: background, what they did, what they found, and finally the point. That is a natural order for telling a story and a poor order for reading under time pressure.

Here is an email from Tomasz Nowak, a network engineer in the network operations center (NOC), to Yara Haddad, the release manager, in both orders.

Subject: core switches

Hi Yara,

As you may know we have had some issues with the core switches since the
summer. There were the two crashes in July and August, and after the
second one we opened a case with the vendor, which took a while because
they first wanted more logs. Last week they finally came back and said
it is a known bug that is fixed in a newer firmware. We tested it in the
lab and it looks fine. So I was wondering if we could plan something for
the update at some point, maybe in the next few weeks? Let me know what
you think.

Thanks,
Tomasz

Subject: Decision by Thu 8 Oct: maintenance window for core switch update (CHG-1192)

Hi Yara,

Can you confirm a maintenance window on Tuesday 13 October, 22:00-00:00,
for a firmware update on both core switches? If that date does not work,
Thursday 15 October at the same time is the alternative.

Why:      The vendor confirmed that the crashes in July and August are a
          known bug, fixed in this firmware. Tested in the lab last week.
Impact:   Switches are updated one at a time. Office network may drop for
          up to 2 minutes, twice. Customer-facing services are not affected.
Back-out: The old firmware stays on the switch; rollback takes 10 minutes.

Details and the lab results are in CHG-1192.

Tomasz

Both emails contain the same facts. The second can be answered in ten seconds, from a phone, with "Tuesday is fine". The first asks Yara to work out what is being asked, by when, and what the risks are, so it waits until she has time, which may be never.

Emails that ask for one clear thing

A call to action is the specific thing you want the reader to do after reading: approve, reply with a date, test a fix, forward a file. In work email it should be explicit, addressed to a named person, and come with a deadline. "Let me know what you think" is not a call to action; "Can you approve this by Thursday?" is.

• One message, one purpose. An email that asks for an approval, reports a bug and proposes a lunch date gets an answer to the lunch date. Send separate messages, or number the questions so each can be answered.
• A subject line that works on its own. Include the action and deadline ("Decision by Thu 8 Oct"), the topic and the ticket or change number. Subjects like "question" or "switches" cannot be found again later.
• To is for action, CC is for information. If three people are in the To field, nobody feels responsible. Name the person in the text: "Hamid, can you check the backup before Friday?"
• Reply-all with care. Before replying to all, ask whether every recipient needs your reply. When you take an email thread to a smaller group, say so in the message.
• Make it easy to say yes. Offer an alternative date, say what happens if they do not answer, attach or link what they need to decide.

Status updates during incidents

A status update is a short, regular message that tells the people affected by an ongoing piece of work, usually an incident, where things stand: what is affected, what is being done, and when they will hear more. During an outage, silence is read as "nobody is working on it", and every person who does not get an update will ask the engineers directly, which slows down the fix.

That is why larger incidents give communication its own role, so the people fixing the system are not also writing messages. The Google SRE book calls the role Communication, "the public face of the incident response task force", whose duties include "issuing periodic updates". PagerDuty's incident response guide splits it into an Internal Liaison and a Customer Liaison. At Kestrel Energy, Ingrid Berg handles major-incident communications. The roles are covered in Working Under Pressure and the ITSM side in Incident management. The communications lead's other tools, such as a status page, are on Incident Response in Practice.

What goes in an update

Tuesday 15 September, 14:40. Some customers cannot pay their bills in Kestrel's customer portal. Here is an update that was really written for the sender, and one written for the readers.

Update: seeing elevated 5xx on payment-gw upstream since the LB config
push, Ravi checking the pool, maybe TLS?? ETA soon hopefully

INC-20702 · Customer portal payments failing · Update 3 · 14:40

Status      Ongoing. Major incident since 14:05.
Impact      About 1 in 3 payment attempts in the portal fails. Logins,
            meter readings and the app work normally.
Workaround  The contact center can take payments by phone.
Now         The portal team is undoing this morning's load balancer change
            (CHG-1187). We will know within 30 minutes whether that fixes it.
Next update 15:10, or sooner if anything changes.

Incident manager: Sanne de Vries. Questions go to #inc-20702, not to the
engineers working on the fix.

The clear update follows a fixed pattern that readers learn to scan:

• A heading that identifies it: ticket number, service, a number for the update, and the time.
• Impact in the reader's terms: what users cannot do, roughly how many, and what still works. "Elevated 5xx" means nothing to the contact center.
• A workaround, if there is one, because that is what most readers can act on.
• What is being done, without speculation about causes that are not confirmed.
• The time of the next update, which is the most important line of all.

Cadence and audiences

Pick an interval, such as every 30 minutes for a major incident, and keep to it even when there is nothing new. "No change since the last update; the rollback is still running; next update 15:40" is a useful message: it tells everyone the incident is still being worked on and when to look again. At Kestrel the interval follows the incident severity: every 30 minutes for SEV-1 and SEV-2 (see severity levels).

Write a separate version for each audience rather than one message that tries to serve all of them:

Paying your bill in My Kestrel is not working for some customers.
We are working on a fix. You can still pay by phone through our
customer service. Meter readings and your account work normally.
Next update by 15:10.

The customer version leaves out internal names, change numbers and technical causes. It also makes no promise about when the fix will be ready, which brings us to estimates.

Estimates and the "when will it be fixed?" question

Everyone wants an end time, and under pressure it is tempting to give one: "should be fixed within the hour". If the fix fails, that sentence has been forwarded to the board, the contact center has told customers, and you have to take it back. Honest options:

• No basis for an estimate: say so, and promise the next update. "We do not have a reliable estimate yet. Next update 15:10."
• A step with a known duration: give that, not the end of the incident. "The rollback takes about 20 minutes; we will know at 15:00 whether it solved the problem."
• A real estimate: give a range and what it depends on. "Restoring from backup takes 2 to 4 hours, depending on how much data has to be replayed."

Reports and summaries for managers

An executive summary is a short opening section, often one paragraph, that gives a decision maker the essentials of a longer report: what happened or was found, what it means for the business, and what decision or action is needed. It must make sense on its own, because for many readers it is the whole report.

Managers usually need different things from engineers: business impact in numbers (customers, money, hours, risk), whether it is under control, and whether they need to do anything. They rarely need the troubleshooting story. The day after the payment incident, Sanne de Vries sends this to management:

Subject: Resolved: portal payments failed for 95 minutes on Tue 15 Sep (INC-20702)

Summary
On Tuesday 15 September from 14:05 to 15:40, about a third of payment
attempts in the customer portal failed. We estimate 1,900 customers were
affected. No payments were lost or charged twice. The cause was a load
balancer change made that morning (CHG-1187); undoing it solved the
problem. No decision is needed from you.

Impact      ~1,900 customers; 310 extra calls to the contact center.
Customers   Status page updated every 30 minutes; no compensation needed
            according to our terms (checked with Legal).
Follow-up   Postmortem on Thursday 17 September. Actions and owners will
            be in the report, by Friday 25 September.

Full timeline: INC-20702.

Notice what is in the first paragraph: the facts a manager would be asked about by their own manager, and an explicit "no decision is needed", which saves a reply. The timeline and technical detail are one link away for those who want them. How to analyze the incident itself is covered in Blameless Postmortems and Learning from Mistakes; regular project status reports, and why traffic lights stay green too long, in Reporting status honestly.

Precision and tone

• Numbers with units and context. "Response time 2.1 s (normally 0.3 s)" says more than "slow".
• Times and dates that cannot be misread. "Tuesday 13 October, 22:00" or 2026-10-13; add the time zone when readers are spread across zones, such as a supplier in another country.
• Clear certainty. Separate what you know from what you suspect: "Confirmed: the change caused it" versus "We suspect the change; testing now". Do not stack hedges ("it might possibly perhaps be"), and do not present a guess as a fact.
• Bad news early and plainly. A deadline that will be missed should be reported as soon as you know, with what you propose. Late bad news removes the reader's options.
• No blame in writing. Describe what happened to systems and processes, not who was careless. Messages get forwarded, and the colleague you blame will read it.
• Plain words. The habits from plain language apply to every audience outside your own team.

Before you send

[ ] The first two lines contain the point or the request.
[ ] The subject line says what it is about and what is needed, by when.
[ ] Each request names a person and a date.
[ ] Times have a date (and a time zone if readers are in several).
[ ] Facts and suspicions are clearly separated.
[ ] Acronyms are expanded or removed for this audience.
[ ] No passwords, no unnecessary personal data, no blame.
[ ] The right people are in To; the rest in CC, or not at all.
[ ] For incident updates: the time of the next update is included.