Write an end-of-day status update people actually read

The "made progress" note that cost me a day

A few years ago I was on a small remote team where the person who looked after deployment config sat seven hours behind me. One Tuesday I finished the payment step of a checkout flow, opened the pull request, watched the unit tests go green, and then hit a wall. The preview environment needed a webhook secret before I could click through the real payment callback, and only she could set it.

My status that evening read like this:

Busy day. Lots of calls. Made progress on checkout. Will continue tomorrow.

She read it on her phone over lunch, saw nothing that involved her, and carried on with her own queue. I logged on the next morning to no secret, a preview I could not test, and a chat message I now had to send and then wait most of a day for an answer to. Setting the secret took her about five minutes once she knew. My note cost a full day because it described my afternoon instead of the one thing somebody else needed to do.

That is the whole problem with end-of-day updates in one example. People forgive a slow day. What they stop trusting is a vague one, because a vague note forces every reader to ping you for the only fact that mattered, usually at a time when you are not there to answer.

Four buckets, in the order a skimming reader needs them

I've settled on four labels and I don't vary them: Done, Open, Blocked, Next. Together they should come in under about 150 words. The limit matters more than it sounds, because the note is usually read on a phone between other things, and anything past the first screen might as well not exist.

• Done is what finished and can be reviewed, with the link that proves it.
• Open is what is still in progress and roughly how big it is.
• Blocked is what you cannot move without someone else: who, what, and by when.
• Next is the single physical action that starts your next session.

Think about what a reader actually looks for. First: am I needed? Second: is progress real, or is this a mood? Third: what is left? Fourth: what happens next, and do I need to plan around it? The four buckets answer those questions, and keeping them in the same order every day teaches people where to look. After a week, your teammates' eyes go straight to Blocked without reading the rest, which is exactly what you want.

Here is the Tuesday from above, written the way I should have written it:

Done - Pull request 482 opened for the checkout payment step. Unit tests are green.

Open - Preview deploy. About one focus block after the secret is set.

Blocked - DevOps: preview webhook secret for the payment callback, needed before tomorrow 14:00 UTC.

Next - After the secret is set: redeploy, click success and failure once, comment on the pull request.

A phone skim finds "DevOps" and "14:00 UTC" without wading through the call list. The calls happened, and they were real work, but none of the readers needed them. If I had wanted credit for the calls, the place for that was my own notes, not a message whose job was to get a secret set.

Five-line status update template

Subject - the work, the day, and the ask in a few words if there is one

Done - reviewable outcome, plus the link or the ticket

Open - what remains, and roughly how much is left

Blocked - who, what, and by when in UTC (or None)

Next - one physical first move

The subject line is the part most people skip, and it is the part that shows up in a notification preview or an email subject. When Blocked is not None, put the ask there too: "Checkout payment step, Tue: need preview secret from DevOps by 14:00 UTC." The person you need can act from the lock screen without opening anything. When nothing is blocked, the subject can be boring: "Checkout payment step, Tue: on track."

Copy those labels as they are. "Still open" is Open. "Tomorrow, first move" is Next. Do not add a sixth bucket for feelings, hours worked, or every ticket you touched. I tried a "Notes" line for a while and it became the place where the actual blocker went to hide.

If a reader cannot find the ask in about ten seconds, rewrite the note. The fix is almost always deleting, not adding. Cut chronology first, because "then I looked at, then I tried, then we had a call" is the part that pushes Blocked below the fold.

If a reader cannot find the ask in about ten seconds, rewrite the note.

Done means someone else could check it without you

Done is the bucket people inflate, and I understand why. A short Done line on a long day feels like a confession. I used to write "worked on checkout" under Done for exactly that reason, and it took a reviewer asking "worked on it how? Is there something to look at?" for me to see what I was doing. That sentence describes effort. It does not describe a state anyone else can check.

My test now: a teammate with the link could review, merge, or verify the thing without asking what I meant. If the only proof is that I was present and busy, the line belongs in Open, or in a private diary that never gets sent.

Open needs a size. "About one focus block," "about two hours," or "three sections left" are sizes. "A bit more" is not, and neither is "nearly there," which in my experience means anything from twenty minutes to a week.

When the end of the day arrives and all I have is a messy log of what happened, I edit it into the four lines in this order:

1. Find the artifact. If a pull request is open and tests are green, Done is that pull request. The calls you survived are not the artifact.
2. Name what is not done, with a size. "Preview deploy, about one focus block" is a size. "Still need to look at preview" is a topic.
3. If a human owes you something, move that fact to Blocked. Do not leave it inside a story about your afternoon, where it reads as background.
4. Write Next as a verb the future you can perform without rereading the diary. Redeploy, click, comment. Not "continue checkout."

Bad days still produce an honest Done. Say you spent the whole day on a payment bug and shipped nothing a reviewer would call fixed. You did not ship the fix, but you probably did something that someone else can follow:

Done - Reproduced the failure on staging. Steps and screenshots are in the ticket.

Open - Fix not started. About two focus blocks.

Blocked - None.

Next - Write a failing test from the repro steps, then open a draft pull request.

"Reproduced" counts as Done because a stranger can follow the steps and see the failure. "Fix not started" sits in Open, said plainly. That note earns more trust than a padded one, because it separates what you know from what you hope.

If you touched three things, the primary thread gets the full four lines. The others get one clause under Open, or "parked, see the ticket." If you cannot paste a link for a Done line, it is not Done yet.

A blocker is a person, an object and a UTC time

A blocked line has three slots. "Waiting on DevOps" fills none of them properly: no person, no object, no clock. "DevOps: the preview webhook secret, before 14:00 UTC tomorrow" fills all three, and it gives the other person something they can do in five minutes rather than a vague sense that you are unhappy with them. The longer version of this argument, including how to avoid sounding passive about it, is in how to report blockers without sounding passive.

Write the deadline in UTC, then check what that means on their wall. In my old setup I was on UTC+2 and the config person was on UTC-5, seven hours behind. My 18:00 was her 11:00, which left her most of a working day to act. My 01:00 (on the rare nights I sent something that late) was her 18:00, which usually meant it landed after she had stopped. A deadline of 14:00 UTC was 16:00 for me and 09:00 for her: the start of her morning, so asking at my 18:00 the day before gave her plenty of room.

The gap also moves twice a year, which catches people out. The EU changes clocks on the last Sunday of October and the US on the first Sunday of November, so for about a week the offset between the two is an hour different from usual. A deadline you wrote as "her morning" can quietly become "before she is online." I've been bitten by that once and now I just write UTC and let each reader convert. More of those traps are in DST mistakes remote teams make.

If Blocked is None, write None. An empty line looks like you forgot, and a reader who cares will ping you to check, which is the exact message the note was supposed to prevent. A severity word can sit beside the owner ("urgent" if it really is), but it does not replace the owner, the object, or the time.

The client version keeps the skeleton and changes the nouns

When I do freelance work, the client gets a version of the same note. I write the internal one first, then make a copy and delete branch names, stack traces, flaky tests, and anything that reads like an investigation diary. What survives is the deliverable, the decision I need, and the links.

I learned to make the decision unmissable the hard way. A small business client once replied "Great, thanks!" to an update where my actual question (keep the international shipping section or cut it?) sat in the fourth paragraph. I took the reply as a yes, wrote the section, and found out a week later that they had never seen the question. Nobody was at fault exactly. The note was just built so that the important line could be skipped.

Now the same update looks like this:

Done - FAQ sections 1 to 4 are in the shared doc (link). Staging screenshots for empty states are in the folder (link).

Open - Section 5, shipping, is waiting on your policy answers.

Blocked - Need you to confirm whether the international shipping FAQ stays or is cut. Choose A or B on the doc comment.

Next - Thursday checkpoint: section 5 drafted after your reply.

Same skeleton, client vocabulary. The decision is a choice between A and B, not "thoughts when you have a moment," which is an invitation to never reply. A client who is busy can answer "A" from a phone. A client faced with an open question tends to wait until they have time to think, and that time does not arrive.

Feedback windows work the same way. If staging is ready and you are waiting on one review pass, Blocked can name the client and the window, and Next can tell tomorrow-you which of two moves is allowed:

Done - Staging link and verify steps are in ticket 88.

Open - Waiting on your consolidated feedback. The window is three business days.

Blocked - None on my side.

Next - If feedback has arrived, apply round one. If it has not, send the nudge the pause terms already allow.

That note documents a feedback delay without a speech, and if the project later slips, there is a dated record of where it was waiting.

Send it while their day can still absorb the ask

I write the note at shutdown, after the evidence exists and before I close the tools. Not later. For a while I wrote it from the sofa after dinner, from memory, on my phone, and those notes were consistently worse: no links, because the links were on the other machine, and a Blocked line that said "secret thing for preview" because I couldn't remember the variable name. The routine around the note is in shutdown routine for ending a remote workday.

The other reason to send early is the person in Blocked. If a human has to act, the note has to leave while their working day can still absorb it. Sending an ask at 23:00 your time, after their office hours have finished, is not diligence. It is a late diary with a deadline attached. On days when I have to leave mid-afternoon for a lift or a school run, I send the Blocked part before I go and finish the rest later, because the person on UTC-5 is only just getting going.

Pick one canonical place for the note and link to it from everywhere else. Posting the same text in five channels creates five slightly different threads by the afternoon, and you will not know which reply is the decision.

Match the ask to the response window the team actually keeps. A status that demands an answer within an hour, inside a team that replies the next morning, is a meeting pretending to be a text field. How those windows should work in the first place is covered in async communication for distributed teams.

If someone else's Blocked line names you, the useful replies are the unblock itself, a UTC time when you will do it, or "not blocked on me, it's Ana's" with the right owner. "Thanks" on its own teaches the team that written asks go nowhere, and next time they book a call.

Status, handoff or meeting

Three artifacts get confused because they all happen near the end of a day. They answer different questions, and using the wrong one is how a perfectly good status note ends up blamed for a failed handover.

A status assumes the reader shares your context and only needs the delta. A handoff assumes they share nothing and have to start work from the note alone, so it needs proof, a precise first move, and a list of things not to repeat. If someone else is continuing tonight, stop using four buckets and write the fuller version in leave work someone else can continue.

If your Blocked line already names who, what, and when, do not also book a panic call unless the deadline has passed and nothing happened. Escalating a clear written ask straight into a meeting teaches everyone that the note was optional.

What a week of these looks like on one feature

The habit pays off over several days rather than one. Here is one payment change across a working week, with the same owner throughout:

Someone who only opens the thread on Friday can still follow the whole chain, and a manager who missed three days does not need a catch-up call. A week of "made progress" leaves nothing to open.

The Friday rollup then writes itself: the same four buckets at week scale, five to ten lines. If the rollup is hard to write, that is usually a sign the daily notes were diaries. On client work the week looks similar with different nouns: Monday's Done is the outline, Wednesday's is sections 1 to 3 plus one recorded decision, Friday's is the revisions and the invoice line.

Bad days still get four honest lines

The days I most want to skip the note are the days it matters most. When an incident replaces the plan, lead with the incident and park the planned work in Open so nobody assumes it shipped quietly in the background:

Done - Incident 44 is mitigated. The timeline and the customer note are in the ticket.

Open - Root-cause write-up, about one block on Monday. The planned FAQ work is parked on its ticket.

Blocked - None.

Next - Draft the root-cause outline from the timeline bullets.

Meeting days are harder because there is nothing dramatic to point at. I once padded a meeting-heavy day into a note that called an outline a "draft," and a teammate cheerfully asked to review the draft the next morning. That was an uncomfortable message to answer. Now I just say what happened, including how little focus time there was:

Done - Decision recorded: provider B, linked from the ticket. FAQ section 1 is an outline only. The longest gap between meetings was 25 minutes.

Open - Sections 2 to 4, about three focus blocks.

Blocked - None.

Next - Protect the morning. Draft section 2 before the first meeting.

Nobody has ever complained about that kind of honesty. It also gives whoever schedules the meetings a fact they can act on, which a padded note never does. Silence after a bad day is the worst option, since it reads as hiding even when it isn't.

The checks I run before I press send

I don't close the laptop on a maybe. If any of these fail, I rewrite before posting. It takes a minute or two.

Tomorrow then starts from the Next line, not from memory, which is a quieter benefit than the team one but probably the one I'd miss most. The point of the note was never to prove you worked; nobody reading it doubted that. The point is that the one person who can unblock you finds out today, while it still costs them five minutes instead of costing you a day.