Weekly Status Report Template: Show Progress and Ask for Decisions
Download a free weekly status report template, see a completed example, and report blockers, delays, next steps, and decision requests clearly.
A weekly status report should show the current state of the work, what changed since the last update, what happens next, and which decisions or help you need. Keep evidence close to each claim. A reader should be able to understand the main risk and required action without arranging another meeting to decode your report.
The template below works in an email or a shared document. It is designed for a small project or an individual's workstream, with enough structure to reveal problems and little room for decorative reporting.
Table of contents
- What belongs in a weekly status report?
- What is the copyable report template?
- What does a completed report look like?
- How do you report delays without hiding them?
- How do you keep reporting useful and brief?
- Frequently asked questions
What belongs in a weekly status report?
Include a dated summary, completed outcomes, the next milestone, risks or blockers, and specific requests. Report the condition of the work rather than proving how busy you were.
Atlassian's status-report guide describes reports as a way to communicate progress and challenges, with frequency adapted to the project. A weekly rhythm is useful when something meaningful can change in a week. It is not a rule for every project.
Use five questions to decide whether a detail belongs:
- Did it change the result or the likelihood of delivery?
- Does another person depend on it?
- Does it explain a material risk?
- Does the reader need to make a decision?
- Will it matter when we compare next week's update?
“Attended three meetings” usually tells the reader less than “Agreed the launch scope with support; the checklist now has an owner.” Activity can be relevant, but explain what it changed.
If your organization requires a particular format, keep it. Use the structure here to improve the substance inside that format, not to create a competing report that nobody asked for.

What is the copyable report template?
Use a short summary followed by evidence, upcoming work, and decisions. Give each request an owner and a date so the reader knows what response is needed.
Download the plain-text weekly status report template, or copy this structure:
| Section | What to write |
|---|---|
| Reporting period | Project, owner, and dates covered |
| Overall status | On track, at risk, or blocked, followed by the reason |
| Completed outcomes | What is finished and where it can be checked |
| Next milestone | Deliverable, owner, and expected date |
| Risks and blockers | Issue, consequence, response, and owner |
| Decisions needed | Decision-maker, options, recommendation, and deadline |
Define status labels with your team. In this template, on track means the agreed next milestone remains achievable; at risk means a credible issue threatens it; blocked means a necessary next step cannot proceed. These are working definitions, not an industry certification.
Write the summary last, after checking the supporting details. If the only decision appears at the bottom, bring it into the opening line too. A busy reader should not have to discover urgency by accident.
Atlassian's weekly-update practice recommends concise asynchronous updates. The benefit comes from making progress and challenges visible, not from choosing an elaborate reporting tool.
What does a completed report look like?
A completed report names the next milestone, explains its status, and makes the reader's action explicit. The following example is fictional; its counts, dates, and outcomes demonstrate the format rather than report real project results.
Customer onboarding refresh — week ending October 9
Owner: Maya Chen
Status: At risk. The October 16 pilot depends on support approval of the revised escalation instructions by October 13.
Completed: Drafted all six onboarding emails. Product review is complete. The review record is in the team's approved project folder.
Next: Alex will check the email rendering by October 12. Maya will prepare the pilot checklist after the escalation wording is approved.
Blocker: The support reviewer is unavailable until October 14. Without another reviewer, the pilot must move or use the existing approved escalation wording.
Decision needed: Jordan to choose an alternate reviewer or approve keeping the existing wording by October 13. Recommendation: retain the approved wording for the pilot and review the revision separately.
The report does not claim “90% complete.” Six drafted emails can be counted, but an unresolved approval can still stop delivery. A percentage that hides a dependency is worse than a clear sentence about what remains.
Notice the difference from a weekly plan: the plan organizes intended work; the report explains what happened and what now requires coordination. Keep both, but do not copy the plan into the report and call future intentions progress.
For decisions made in a meeting, link to the relevant meeting notes. Readers should be able to trace a changed deadline or scope without searching several channels.

How do you report delays without hiding them?
State the change, consequence, recovery option, and decision needed. Send urgent risks when they emerge rather than waiting for the weekly report's scheduled delivery.
For example: “The review is two days later than planned because the required approver is unavailable. That moves testing unless we reduce the pilot scope. I recommend testing the approved core flow first; please confirm by Tuesday.” This is a fictional communication example, not a promise that reducing scope is always appropriate.
Avoid “There may be some slight delays” when you already know which milestone is affected. Also avoid blaming a person when the actionable issue is an unavailable approval, missing input, or unclear requirement.
Atlassian's report guidance includes making challenges visible. Our practical extension is to attach a decision to the warning whenever a decision could change the outcome. If no decision is needed, say what you are doing and when you will report again.
Do not label everything green because most tasks are complete. Judge the milestone using its critical dependencies. A single missing item can matter more than a long list of finished tasks.
How do you keep reporting useful and brief?
Reuse reliable work records, keep the reporting period consistent, and remove fields that do not help anyone decide or coordinate. The report should be an accurate view of the work, not a second project.
Start from your delivery checklist, decision log, and last report. Check whether earlier requests were answered. Mark a risk resolved only when its consequence has actually been addressed, not because the discussion went quiet.
A practical editing pass asks three questions: Is the opening accurate? Can each claim be checked? Is every request answerable? These are editorial checks, not research-derived performance targets.
Atlassian suggests reserving a few minutes on Friday for its weekly-update practice. Choose a time that fits your recipients' decisions. A Friday report is too late if they need to allocate resources Thursday.
Move the agreed next steps into a daily planning template. If the report exposes more work than you can responsibly finish, renegotiate scope or timing instead of polishing the same optimistic story next week.
Do Only 3 Things a Day adds a daily card, the Choose, Protect, Do, Review loop, and a seven-day start. The report shows the work's condition; the daily system helps you change it.
Frequently asked questions
How long should it be?
Long enough to explain the state and decisions, short enough that the intended reader will use it. Start with one screen or a short page, linking supporting detail. Treat that as a practical constraint, not a universal word limit.
Should I use email or a document?
Use the place your team already checks. Email can suit a small, stable audience; a shared document can preserve history and discussion. Keep one authoritative version so different copies do not drift apart.
What if nothing changed?
Say what remains unchanged and why. A quiet week may be expected, or it may reveal a blocker. Confirm the next milestone and whether any previous request is still awaiting an answer.
Is a weekly report the same as a timesheet?
No. A timesheet records time under the relevant organization's rules. A status report communicates progress, risks, and decisions. Time spent may explain a constraint, but it does not by itself establish that an outcome was delivered.