A project status report template is a one-page summary of where a project stands: work done, what's next, budget and schedule, action items, and issues and risks. ProjectManager defines it as a document that describes progress within a specific time period and compares it against the plan.
That comparison is what separates a status report from a to-do list. Anyone can say what got done. A useful report says whether that's where you expected to be by now, and what you're doing about it if it isn't.
The layout
ProjectManager lists the contents as work completed, the plan for what follows, a budget and schedule summary, action items, and issues and risks with what's being done about them. I've added an overall status line at the top, so a reader gets the headline first.
| Section | What to write | Length I'd aim for |
|---|---|---|
| Project basics | Project name, who's running it, the date and the period covered | One line |
| Overall status | On track or not, in plain words, plus any decision you need | Two sentences |
| Work completed | What's finished since the last report | Three bullets |
| Next period | What's planned before the next report | Three bullets |
| Budget and schedule | Forecast against actual, and the expected finish date | Two lines |
| Action items | What needs doing, by whom and by when | One line each |
| Issues and risks | What's wrong or might go wrong, and what's being done | One line each |
Copy this template
PROJECT STATUS REPORT
Project name, project lead, date, period covered
Overall status: on track, at risk or off track, in one sentence
Decision needed: what you need, from whom, by when (or write none)
Work completed this period: up to three items
Planned for next period: up to three items
Budget: forecast compared with actual so far, and why any gap exists
Schedule: planned finish date compared with the current expected date
Action items: task, owner, due date
Issues and risks: the problem, what's being done, who's handling it
What goes in each section
Project basics. ProjectManager's advice is not to assume your reader knows them. It sounds too obvious to bother with, but it matters when someone new joins, or when you're looking something up a year later.
Work completed and next period. Stick to outcomes, not activity. "Landing page live" tells a reader far more than "worked on landing page". As of Nov 2026, the Confluence template on Atlassian's site gives stakeholders an overview of the latest accomplishments, next steps, and risks or issues, which is close to the same shape.
Budget and schedule. ProjectManager says one of the main purposes of the report is to compare progress with the plan's estimates, so include a short summary of the forecast finish date and costs. Don't list every line item. Show the gap and explain it.
Action items, issues and risks. These are the rows a reader can do something about. Atlassian says project teams can use status reports to identify potential risks and issues early, and an early warning's only useful if it arrives with what you're doing about it.
Writing it without losing your afternoon
- Decide what it's for and who's reading it. ProjectManager starts with the objective and the audience, since clients and team members want different things.
- Gather your data. Pull completed tasks, costs and dates from wherever they live.
- Compare with the plan. Note where you're ahead, behind or over.
- Write up to three lines per section. If it needs more, it probably belongs in a separate document.
- Flag decisions. Move anything you need from the reader to the top.
- Edit, send and file. ProjectManager ends with making it clear and editing the draft. I'd add saving it in the same place every time.
If you're writing these often, these prompts for project managers can help turn rough notes into a first draft, though you'll still need to check every figure yourself.
How often to send it
There's no single right answer. ProjectManager says reports can be daily, weekly, monthly or quarterly depending on what the project needs, and Atlassian says the timing should balance how often you update with how complex the project is and what stakeholders expect.
| Rhythm | What it's good for |
|---|---|
| Daily | What each team member worked on, and what's blocking them |
| Weekly | A summary of the week's work, the plan for next week and any challenges |
| Monthly | A recap for leadership, plus the next month's activities |
For most small business projects, I'd start weekly and slow down if nothing's changing between reports. A report with nothing new in it teaches people to stop opening the next one.
Why the old reports matter more than the latest one
Here's what most people miss. ProjectManager says the true value of a status report goes beyond communication, because it also gives you a documented history of the project. Next time you plan something similar, you can look back and avoid the same missteps and bottlenecks.
Want AI doing the heavy lifting in your marketing?
I build the systems that handle the boring 80 percent, so you get your week back. Done properly, with the human kept in.
That changes how you should treat the file. A report that's emailed and forgotten only does half its job. So I'd keep every issue in one folder with the date in the file name. It costs you nothing, and six months later you can see exactly when a delay began.
One thing to know about templates: ProjectManager points out that a template's a static document, and it sells software that fills these in automatically, so bear that in mind when you read its advice. If you're pulling numbers by hand across several projects, it may be worth comparing portfolio management software or AI project management tools. For a single project, a document's usually fine.
Where I land on status reports
The honest downside is that a status report can turn into theatre: lots of effort, everything marked fine, and nobody reading it. ProjectManager warns against bogging stakeholders down with unnecessary details, and that's how most of these reports die.
The upside is worth having, though. Atlassian says Arizona State University's project management office created its template to standardise how it keeps stakeholders up to date across all its projects. A consistent format like that saves time every cycle, and it makes a handover far easier because the history's already written down.
I'd lead with the decision you need, keep it to one page and skip any section your reader doesn't act on. If somebody asks a question that the report should've answered, add that. If nobody's commented on a section in a month, cut it.
Frequently asked questions
What is a project status report?
ProjectManager defines it as a document that describes the progress of a project within a specific time period and compares it against the plan. It's taken repeatedly throughout every phase, to keep the schedule on track and stakeholders informed.
What should a status report include?
ProjectManager lists work completed, the plan for what follows, a summary of budget and schedule, action items, and issues and risks with what's being done about them. I'd add one line at the top with the overall status.
How often should you send one?
ProjectManager says daily, weekly, monthly or quarterly can all work, depending on your project. Atlassian says the timing should suit the project's complexity and what stakeholders expect. I'd start weekly and adjust from there.
How long should it be?
ProjectManager advises keeping it light and to the point for stakeholders, and I'd aim for one page. If it won't fit, link to the detail instead of pasting it in.
Who is it for?
It's usually for clients, team members and anyone else with a stake in the project, and ProjectManager says to target your audience before you write. If those groups need different things, I'd send a shorter version to the people who only need the headline.
