How to write a monthly report: how it differs from a weekly report
Last updated September 26, 2026
A monthly report groups the month’s finished work by project or goal and shows what changed compared with last month. Four sections cover most teams: a summary, results by project, next month’s plan, and decisions needed. Stapling four weekly reports together makes it long and leaves the reader hunting for the point.
How is a monthly report different from a weekly report?
Different readers want different answers. Close teammates and your manager read a weekly report to see whether things are on schedule. A monthly report also reaches your manager’s manager and other team leads, who want to know what the team achieved this month and whether it moved closer to its goals.
So the unit of a line changes. A line in a weekly report is one task; a line in a monthly report is one project or goal. Most individual task names drop out, and only the results they added up to remain.
What goes in a monthly report?
- Summary: the two or three most important results of the month. Busy readers stop here.
- Results by project: for each project or goal, what finished this month, a number that shows the result, and what’s left.
- Next month: where each project will be by the end of next month.
- Decisions needed: what the reader has to do. Say who needs to decide what, and by when, and the report doubles as a request.
Put numbers next to last month or the target. Refund API at 0.6s tells the reader nothing on its own; down from 1.8s to 0.6s reads instantly.
How do you turn four weekly reports into one page?
Gather the month’s finished work by project, then merge the lines that led to the same result into one. Lead the merged line with the result, and add the process only when it matters.
- Before
- 9/2 Retry queue design review
9/9 Retry queue development
9/16 Retry queue QA
9/22 Retry queue shipped to production - After
- Shipped the payment retry queue. Manual reprocessing requests down from about 20 a week to one or two
Work that showed up in all four weekly reports became one line. Design, development, and QA were how the result happened, so they drop out of the monthly report. If someone asks about the process, show them the weekly reports.
On the other hand, work that sat in progress all month should stand out more in the monthly report. Say why it didn’t finish and when it will.
Monthly report template and example
Here is a September monthly report from Dana, the payments team lead. Keep the section names and order, and change the contents.
- Shipped the payment retry queue. Manual reprocessing requests down from about 20 a week to one or two
- Cut average refund API response time from 1.8s to 0.6s
- Automated settlement report emails slipped to October while we agreed on criteria with Finance
- Reliability
- Retry queue in production (9/22), dead-letter alerts added. Payment failure rate 1.2% in August, 0.8% in SeptemberLeft: failure reasons dashboard by card issuer
- Subscriptions
- Card update screen shipped (9/30). Expired cards caused 31% of August cancellations; October churn will show the effect
- Settlement
- Report email design final, development in OctoberWhy it slipped: agreeing on recipients with Finance took two weeks
- Automated settlement report emails live, target 10/24
- Launch the failure reasons dashboard by card issuer
- Share October subscription churn alongside August and September
- Who owns renewing the card issuer test account. It expires 10/2, so Ops or Payments needs to be named today
The summary alone tells you how the month went, and every number in the project section sits next to last month’s. The late item is called late right in the summary, with the reason.
What are common monthly report mistakes?
Stapling weekly reports together, giving numbers with nothing to compare them to, reporting only good news, and reconstructing the month from memory on the last day.
Stapling weekly reports together
Four weeks pasted together show the same work four times and a conclusion nowhere. The reader has to do the grouping, and the writer is the one best placed to do it.
Numbers with no comparison
This month’s number alone doesn’t say whether things got better or worse. Put last month or the target beside it, and if it’s a new metric with nothing to compare, say this is the baseline month.
Only good news
Leave out what slipped and it all surfaces next month at once. Stating the reason and the new date up front is what makes the rest of the report believable.
Reconstructing the month on the last day
A month is four times longer than a week, so memory drops the first week’s work first. Build up the material as you go, so there is nothing to recall at month-end.
How do you avoid reconstructing the month at the end?
Your weekly reports are the raw material. If each line ends on a result and a number, month-end is just laying out four reports and grouping by project. Weekly reports that only describe activity can’t become a monthly report, and you end up digging through memory again. How to end a line on a result is in How to write a weekly report.
Tagging each task with its project when you write it down saves the grouping step too. At month-end you only read and merge lines that are already sorted.
Doing this in DDirong
DDirong is a web app that keeps tasks, schedules, work logs, and weekly reports in one place, and its recording features are free. Add # to a task to put it in a workspace, which keeps work split by project, and when you check it off a result memo box opens for a line or two about what happened.
There is no monthly period to pick. For a monthly report, set the period to All and copy completed tasks as performance review text. You get completed work grouped by workspace with dates; keep the lines from that month and use them as material for the results section. Memo text isn’t included, so fill in the numbers while reading your memos in the app.