The status update email is one of the most common documents in professional life and one of the most commonly mishandled. Too long and people skim past the important parts. Too vague and you'll spend the next two days fielding clarifying questions. The goal is simple: give readers exactly what they need to know, in the order they need to know it, with enough specificity to trust it.
What a good status update email actually does
A status update email serves three readers at once. First, the person who asked for it wants confirmation that things are on track (or an honest account of where they aren't). Second, anyone CC'd on the thread wants enough context to follow along without asking questions. Third, you, the sender, want to protect your professional credibility by showing that you're on top of the work.
Those three goals pull in slightly different directions, which is why most status updates feel off. They either over-explain for the CC crowd, or stay so brief that the primary reader has to chase down details. The fix is structure, not length.
The four-part structure that works
Every status update email worth reading covers four things in this order:
- Current state. One sentence on where the project stands right now.
- What's been completed. The specific tasks or milestones finished since the last update.
- What's next. The 2 or 3 concrete actions that will happen before the next check-in.
- Blockers or risks. Anything that could delay progress, named plainly and paired with a proposed solution.
You don't need headers for a short update. For anything longer than 150 words, short bolded labels help readers scan without reading every line.
The subject line matters more than most people think
A subject line like "Update" or "Project status" tells the reader almost nothing. It also makes the email hard to find later. Write a subject line that names the project and the date, or the milestone: "Supplier portal rollout: week 12 status" or "Client onboarding process: end of sprint 3." Those subjects can be searched, sorted, and understood at a glance. For more on how subject lines shape open rates and reader trust, see the post on subject lines that get your email opened.
How to handle bad news in a status update
This is where most writers go wrong. When a project is behind schedule or a deliverable has slipped, the instinct is to bury the bad news in qualifications or save it for the third paragraph. Don't. Put the problem in the first two sentences, state the cause in one clause, and follow immediately with what you're doing about it.
Compare these two versions:
Version A: "The team has been working hard and has made good progress on several fronts. There have been some challenges with the data migration that have led to a slight delay, though the team is confident this will be resolved soon."
Version B: "The data migration is currently 4 days behind schedule due to a schema mismatch discovered during testing. The technical team identified the fix on Tuesday and expects to complete the migration by Friday 29 August."
Version B names a number, a cause, and a date. Version A names nothing. Readers trust Version B even though it contains worse news, because specificity signals control.
Tone: confident but not overconfident
Status updates are not the place for hedged language or corporate padding. Phrases like "we hope to," "it is anticipated that," or "efforts are ongoing to ensure" tell the reader that you're not certain about anything. If you genuinely don't know a completion date, say that directly: "We're targeting the 5 September handoff, but I'll confirm once the vendor responds." That's honest and still useful.
At the same time, avoid the opposite extreme. "Everything is perfectly on track and no issues exist" raises eyebrows on any complex project. One or two named risks (even minor ones) show that you're paying attention.
How long should a status update email be?
For a weekly team update on an active project: 100 to 200 words. For a milestone update going to a senior stakeholder: 150 to 300 words with a clear subject and bolded labels. For a full project status report attached as a document: the email itself should still be under 100 words, pointing the reader to the attached document for detail. Anything beyond that lives in a report, not an email.
If you're struggling to keep updates short, the problem is usually that you haven't separated tasks from outcomes. Tasks are what the team did. Outcomes are what changed as a result. Readers want outcomes. Cut the task list and replace it with the result each task produced.
The opening sentence sets everything
Don't open a status update with "I hope this email finds you well." It wastes the reader's first second and signals that nothing urgent follows. Open on the current state of the project. "The website migration is on schedule for a 1 September launch" is a complete first sentence. Your reader knows what they're dealing with before they reach the second line.
The same principle applies to follow-up updates on threads that have gone quiet. If you're writing because someone hasn't responded and you need a decision before work can continue, name that clearly in the opening. For guidance on wording in those situations, the post on how to write a follow-up email after no response covers the timing and language in detail.
A short template you can adapt
Subject: [Project name]: status update [date]
Current state: [One sentence.]
Completed since last update: [2 to 4 bullet points, each one naming a specific deliverable or milestone, not a task.]
Next steps: [2 to 3 bullet points with owner names and target dates.]
Risks or blockers: [Name the issue and the proposed action. If none, write "No blockers at this stage."]
That structure works for project updates, client reports, and internal team emails equally well. Adapt the label wording to fit your context, but keep the four parts intact. Readers who receive updates in this format regularly stop asking "can you send me an update?" because the updates arrive before they need to ask.
One final point: if your status update ends up doubling as a record of decisions made in a preceding meeting, it's worth treating it like a meeting recap email. The two formats overlap more than people expect, and combining them saves everyone from receiving two separate emails when one would do.