A Weekly Status Report Template People Actually Read

Friday afternoon. You spend an hour pulling every project’s status into one document and send it to eight stakeholders. Three open it. Two read the first line. One replies asking a question the report already answered, three paragraphs down.

A good weekly status report leads with what changed, names every blocker with an owner and how long it’s been stuck, gives quiet projects one line or none, and links each claim to its source. It should be readable in under a minute. The template below does that, and works as an email or a Slack post.

Most status report templates fail the same way: they give every project the same paragraph whether anything happened or not. That covers everything, but the two lines a reader actually needs end up buried in the middle.

The weekly status report template

Copy this into an email, a Slack post, or a doc. Delete any section that’s empty this week. Don’t fill it with “no updates”.

Weekly update: [team or project], week of [date]

THE HEADLINE
[One sentence: the most important thing that changed this week.]

SHIPPED
- [What shipped] ([link to PR, release, or ticket])

BLOCKED
- [What's blocked]: waiting on [person or team] for [what], [N] days ([link])

DECISIONS MADE
- [What was decided] ([where: meeting, Slack thread, or doc link])

NEXT WEEK
- [The one or two things that will change next week]

NO CHANGE
[Project A], [Project B]

Five rules make it work:

1. Lead with the headline. If someone reads one line, it should be the one that matters.
2. Every blocker gets a name and a number. “Blocked on security review” is easy to skim past. “Waiting on Priya for security sign-off, 4 days” gets action.
3. Link everything. A claim with a ticket or PR link behind it can be checked. A claim without one has to be taken on trust.
4. Quiet projects get one line, together. Projects that didn’t move go in “No change”. They don’t each get a paragraph explaining that nothing happened.
5. Let the length change. Some weeks are four lines. Some are longer. The report should be as long as what actually happened.

A filled-in example

Here’s that template for a team running five projects in a normal week:

Weekly update: Platform team, week of Sept 22

THE HEADLINE
Cascade v2 shipped Tuesday, the release Product has been waiting on.

SHIPPED
- Cascade v2 is live, no issues so far (release PR #1184, on-call log)

BLOCKED
- Beacon: waiting on Priya for security sign-off, 4 days (SEC-212)

DECISIONS MADE
- Atlas will use the existing auth service, not a new one (Tuesday's design review notes)

NEXT WEEK
- Beacon launches if sign-off lands by Wednesday

NO CHANGE
Delta, Echo

Compare that to the version most teams send:

Project Atlas: on track, team continues work on the API integration, expect completion next sprint. Project Beacon: in progress, some blockers being worked through, more updates to follow. Project Cascade: shipped v2 this week, monitoring for issues. Project Delta: no significant updates. Project Echo: kickoff meeting held, next steps being defined.

Five paragraphs, all in the same tone. The release Product cared about sits third. “Some blockers being worked through” hides the fact that one person has been holding Beacon up for four days. The template version is shorter and says more, because it only reports what moved.

Why most weekly status reports get skipped

They’re written so nobody can say they weren’t told, rather than so anyone can act on them. That’s a reasonable instinct, but the result is a document built to prove coverage. A stakeholder who cares about one project has to read past five others to find it, and most people stop after the first paragraph or two that don’t apply to them.

Both sides pay for it. The writer spends an hour or more formatting and cross-checking instead of thinking about the work. The reader technically received the information, so when a question comes up later the answer is “it was in the status report”, even though nobody got it from there.

How to fill it in without spending your Friday on it

The slow part isn’t writing. It’s finding out what actually happened: which PRs merged, which tickets moved, what got decided in a Slack thread you weren’t in, which blocker has been sitting since Monday. That’s an hour of clicking through Linear or GitHub, Slack, and meeting notes, then working out which of it matters.

That’s the part Thor handles. Thor drafts the update from what actually happened across your tracker, Slack, GitHub, and meetings, with links back to where each item came from. You review and edit it before anything goes out. That review step matters here, because a stakeholder update is often the only view an outside audience gets of how a project is going, and the lines that name a blocker or a delay are exactly the ones that need to be right.

The “Decisions made” section is usually the hardest to fill, because decisions happen in meetings and threads, not in the tracker. Here’s what happens to meeting decisions and action items after the call ends. If your team also posts daily updates, the same approach works for stand-ups.

FAQ

What should a weekly status report include?

A one-line headline, what shipped, what’s blocked (with who it’s waiting on and for how long), decisions made, and what’s next. Projects with no change get listed together in one line. Link each item to its ticket, PR, or meeting notes.

How long should a weekly status report be?

As long as what changed, and no longer. In a quiet week that might be four lines. A reader should be able to get the important part in under a minute.

Should I skip projects that had no news this week?

List them together in a single “No change” line. That way nobody wonders whether a project was forgotten, and the projects that did move get the reader’s attention.

Should I send it by email or post it in Slack?

Wherever your stakeholders already read. The template works in both. Slack is better if people tend to reply with questions. Email is better for readers outside the team.

Can a weekly status report be automated?

The gathering can be. Thor drafts it from your tracker, Slack, GitHub, and meetings, with sources linked. A person should still read and approve it before it’s sent, especially the lines about blockers and delays.

Want your weekly update drafted from what actually happened, ready for you to check and send? Book a demo and see Thor in action.