How to write async status updates people actually read

The answer was in paragraph two

A designer on a remote team I worked with once replied to my end-of-day update with a question: "Is the new pricing table safe to show the client tomorrow?" Fair question. It was also answered in my update, in the third sentence of the second paragraph, after a bit about a flaky test and a bit about how the morning had gone. She had read the first two lines, found nothing she could use, and asked me directly. She was six hours ahead, so my reply reached her at the start of her next day, which was the morning of the client call.

Nothing broke. She showed the table and it was fine. But I reread my update afterwards and saw it for what it was: a diary. It told the story of my day in the order I lived it. The one fact anyone else needed was in there, technically, the way a USB cable is technically in the drawer full of other cables.

I've found most status updates fail in exactly this way. They are not lazy and they are not dishonest. They are written for the writer. What fixed mine was less a new format than a set of habits for building each line, so that someone skimming at the start of their day finds what they need in one pass and can stop reading without a follow-up message.

The copyable end-of-day template, and the question of when to send it, live in the end-of-day status update. The habits below are about what goes inside each line.

Four labels, always in the same order

Use the same skeleton every day so people learn where to look. Once readers trust the shape, they stop reading your update as prose and start reading it like a form, which is exactly what you want from something they open between two other things.

Done: one to three items, each with a link or a ticket number.

Open: what you are actively doing next, with its review state ("PR ready", "draft, comments welcome").

Blocked: one line per blocker, written as an ask with a name and a date. Or the word "none".

Next: the first physical thing you will do when you sit down again.

The order matters more than it looks. For a few weeks I put Next at the top because it felt more forward-looking. A QA colleague told me, politely, that she had stopped trusting it, because she could no longer tell at a glance what had actually finished. Done first is boring. Boring is the point. The reader who only reads one line should get the line that is already true.

Done first is boring.

Rewriting weak lines

The most common weak update I see, and have written, is this:

"Made progress on checkout, no blockers."

That line makes two claims and offers no evidence for either. "Progress" could mean anything from "opened the file" to "one test away from merging". "No blockers" is often untrue in a way the writer has not noticed yet: they are waiting on something they have mentally filed under later.

The strong version:

"Done: EUR tax line on staging (ticket 441). Open: USD rounding edge case in branch fix/usd-round. Blocked: need Legal copy for the error state by Wed, asked in 441. Next: open the PR and tag QA when the copy lands."

Every reader gets something different from that. The project manager can reschedule without a call. QA knows what to test today and what to leave alone. Legal sees a dated ask sitting in the ticket where approvals belong, instead of a mention in a channel they muted. Nobody needs to message the writer, which across time zones means nobody loses half a day waiting for an answer.

A few more pairs I've collected from my own old updates:

Notice what the strong column has in common. Nouns you can click or search for. Numbers instead of adjectives. A state ("fails", "ready", "open until Thu") instead of a feeling about the state.

A link does the arguing for you

A line without a link asks to be believed. A line with a link shows its working. Paste the pull request, the doc section, the dashboard, the permalink to the ticket comment. If the work is not linkable yet, name the file path and the review state.

I learned this one with a freelance client rather than a team. I told a small business owner by email that her booking page was "basically done". She replied with a screenshot of the live site, which still showed the old page. She was right to. "Basically done" on my side meant finished on staging. On her side there was nothing to look at, so it read as a promise. Every Done line in a client email of mine now has something she can click, even if it is a staging link that expires next month.

One more habit here: when yesterday's link is still the relevant one, update the ticket instead of repeating yourself in chat. One home for the truth beats three copies drifting apart. Chat should point at the durable thing, never replace it.

A no-change update is still an update

The annoying part about slow days is that skipping the update feels modest. Nothing happened, so why bother anyone? But silence does not read as "nothing happened". It reads as "all fine" to the optimists and "something is wrong" to the worriers, and both groups plan around their guess.

One line covers it: "No change on 512. Still blocked on Legal, pinged again this morning, next action Wed AM." That is useful status. It stops someone planning around a progress bar that only exists in your head.

Cadence should follow how often other people depend on your output, not how guilty you feel. Daily makes sense on active projects. Twice a week is plenty for a quiet maintenance retainer where the client mostly wants to know nothing is on fire.

Blocked lines that get one reply

Blocked lines fail when they describe a mood. "Waiting on DevOps" tells the reader you are unhappy and gives them nothing to do. "Need production log access for job 884, asked Sam, need it by Friday for the release" gives one person one decision and one date. That is answerable in a single reply, which is the only kind of reply that works well across a six-hour gap.

Tone matters as much as fields here, especially when you have asked twice already. Reporting blockers without passive aggression goes through the wording that keeps the second and third ask from sounding like a complaint.

If you are ahead of or behind the person you are blocked on, say when you will next read replies: "I'll pick this up at my 09:00, your 15:00." It saves them wondering whether a midnight answer is expected. Async response expectations across time zones covers reply windows properly.

Same bones, different readers

Team channel: the four labels, bullets, links. No greeting paragraph, no sign-off.

Client email: the same bones with a little more context on Done, and no internal ticket numbers. Clients care about milestones they can open or test. A Done line might read "Staging link for the revised signup flow, steps 1 to 3 match the wireframe you signed off". Open: "Payment step next, expect it for your review Wednesday." Blocked: "Need sandbox credentials from the payment provider, requested Tuesday morning, need them by Thursday to keep Friday's demo." Next: "Send you a short test script Friday morning your time."

A lead's rollup: when the project is in trouble, put Blocked and Next above Done. A worried reader wants the risk first.

Change the order for the reader's urgency. Never change it for storytelling.

Handoffs get a fifth label

Handoffs are where the four labels earn their keep. Say it is Friday, a database migration is half done, and the next owner is nine hours ahead and will start Monday before you are awake. The weak note is "Migration going well, will continue Monday", which hands them a mystery. Add a Handoff label and it becomes something they can execute.

A status update for a nine-hour handoff

Done: staging database cloned, migration runs through step 4 (ticket 902, log attached)
Open: step 5 stalls on index creation timing
Blocked: need the DBA to confirm a maintenance window, asked in 902, need answer by Sun 18:00 UTC
Next: run step 5 in the approved window, then the smoke test checklist in 902
Handoff: branch migrate/902, credentials path noted in the ticket, run make migrate-dry before anything live

Monday starts with execution instead of archaeology, and nobody pings you at your midnight because the ask is already dated and located. Leaving work someone else can continue goes further on what a good handoff needs. The small companion habit: on Monday, open with one line of context, "Picking up from Friday's handoff, branch X, waiting on QA". That line alone saves a few pings before lunch.

Length is not proof of effort

Some people write long updates because long feels accountable. I did, in my first year on a distributed team. I thought a full paragraph showed I had been working. Readers experience the opposite: they cannot see what changed since yesterday, so they stop opening the thread, and the long writer gets less credit than the short one.

What reads as accountable in async work is a visible change in state. "Worked on API" is activity. "Webhook signature validation merged, staging link in ticket 77" is a finished thing someone can rely on. People planning from your status need the second kind. Busy versus finishing work is the longer argument for why that difference matters beyond status notes.

If something took longer than expected and you want to explain why, put the explanation in the ticket history. Future you will search there. The daily update is not the place for it.

Read it as a stranger before you send

Write the update from what is open on your screen, not from memory. Memory smooths over gaps. The ticket you forgot to link is the one somebody will ask about.

Then read it three times, quickly. Once for missing links. Once for blockers without an owner or a date. Once as if you were covering for a teammate on holiday and this note was all you had. Cut adjectives that change nothing about planning, words like "significant", "various" and "ongoing", and put a noun someone can click where they were.

The test I use now comes from that designer's question about the pricing table. If someone can read my update and still needs to message me before they can start their day, the update did not do its job. The fix is always in the line, never in the reader.