Weekly status report template
Use the fill-in version on this page: type your week, choose plain text, Slack or email, and copy. Nothing you type is saved or sent anywhere. Below you will find the blank template, what belongs on each line, two worked examples, and the one ordering decision that separates a weekly report people read from one they skim.
The blank template
Week of:
Summary:
Shipped:
On track:
At risk:
Decisions needed:
Next week:
Links:
What goes on each line
Summary. One sentence a busy reader could stop at and still know how the week went. "Good week: checkout ships Friday, but the data migration has slipped a week." Many readers will read this line and nothing else, so it has to carry the bad news as well as the good.
Shipped. What reached done this week.
On track. Work in progress that will land when expected. Keep it short. This is the section readers skim, and it is fine for it to be skimmable.
At risk. What might slip, why, and the new expected date. This is the section that earns the report its place in someone's inbox.
Decisions needed. What you need someone else to decide, who that is, and by when. A decision request without a deadline tends to wait until it is urgent.
Next week. The two or three things that matter most. Not everything you will touch, just the things you would want the reader to ask about.
Links. Dashboards, documents, tickets: whatever lets the reader check a claim without asking you.
Why "at risk" sits above "next week"
Weekly reports fail in a predictable way: the good news goes first, the risk goes last, and the reader stops before reaching it. By the time the slip is visible it is a surprise, and surprises are what weekly reports exist to prevent.
So the order is deliberate. The summary carries the headline, including any bad news. Risk and decisions come before plans, because they are the parts that need the reader to do something. Plans come last, because they are the part the reader can safely skip.
Worked examples
These are illustrative. The names and figures are made up to show the shape.
Engineering lead to a founder
Week of: 2026-09-21
Summary: Good week overall; billing ships Thursday, but the search rebuild has slipped by a week.
Shipped: Invoice emails; the admin audit log
On track: Billing page, landing Thursday behind a feature flag
At risk: Search rebuild. The new index needs a data backfill we did not plan for. New date: 2 October
Decisions needed: Whether to ship billing to everyone Thursday or to ten accounts first. Need it by Wednesday
Next week: Billing rollout; start the search backfill
Links: Sprint board; billing preview link
Why this works: the slip is in the first line, with a cause and a new date, and the one decision has a clear owner and deadline.
Agency or freelancer to a client
Week of: 2026-09-21
Summary: Design sign-off is complete; development starts Monday on schedule.
Shipped: Final homepage and pricing page designs, approved in Wednesday's review
On track: Content migration, 60 of 85 pages moved
At risk: Product photography. If it arrives after 30 September, launch moves by the same number of days
Decisions needed: Which of the two contact form options to build. Need it by Friday so it fits next week's sprint
Next week: Development on the homepage and pricing pages
Links: Design file; migration tracker
Why this works: it ties the risk to a date the client controls, which turns a vague worry into a decision they can make.
Weekly status report or daily report?
A daily report covers one person's day, for someone close to the work. A weekly status report covers a team's or a project's week, for someone further away: a founder, a client, a stakeholder. The weekly one needs more judgement about what matters and less detail about what happened.
If you already collect daily reports, most of the weekly one writes itself from them. For the daily version, see the end-of-day report template. For the formal project version, with RAG status, see what is a status report.
If you are the one reading ten of these
Weekly reports compiled by hand tend to drift toward optimism, because the person writing them is summarising from memory.
Every Eodly plan sends a daily report built from the check-ins your team already sends, weighed against what actually moved in GitHub and Linear. On the Scale plan, it adds weekly and monthly rollups with trends on top, so the week is assembled from that record rather than recalled from memory.