This post answers what is a status report in more detail: who it is for, what goes in it, how it differs from a progress report and a client update, how often to send one, and how to write a status report. It ends with three worked examples you can copy.
What is a status report?
A status report is a written summary of a project's current position, shared on a regular schedule. Its job is to let someone who isn't doing the work understand, in a few minutes, whether the project is on schedule and whether they need to act.
A project status report usually covers one reporting period, such as the past week. It compares where the work is with where the plan said it would be. If something has slipped, it says why and what happens next.
A status report is not a diary of everything the team did. It is a summary for a reader who needs to make a decision or plan their own work.
Who is a status report for?
The reader decides what goes in. Typical readers are:
- Your own team. They need task owners, handoffs, blockers and dates.
- A manager or project sponsor. They need to know whether the project is on schedule, what is at risk, and what they need to approve.
- Other teams that depend on your work. They need dates and anything that changes their plans.
- A client. They need results, decisions and dates, in plain words. For clients, a shorter client update usually works better (more on this below).
If you have more than one kind of reader, you may need more than one version. The facts should match in every version. Only the level of detail should change.
What goes in a project status report?
Most status reports use the same core sections. Keep each one short.
- Project name, period and date. For example, "Website refresh, week of 1 June."
- Overall status. One line: on track, at risk or off track. Add one sentence that explains why.
- Done this period. Finished results, not a list of activity.
- Next period. What the team plans to finish next, with dates.
- Risks and issues. What might go wrong or has gone wrong, what it affects, and what you're doing about it.
- Decisions needed. What you need, from whom, and by when.
- Changes. Any change to scope, dates or budget since the last report.
Some teams add budget used, hours spent or other measures. Include these when your reader uses them to make decisions. Leave them out when they only add length.
Status report vs progress report vs client update
A common follow-up to "what is a status report" is how it differs from a progress report and a client update. Here is how the three compare.
| Status report | Progress report | Client update | |
|---|---|---|---|
| Main question | Where does the project stand right now? | How much work was completed over a period, compared with the plan? | What changed for the client, and what do they need to do? |
| Typical reader | Team, manager, sponsor | Sponsor, funder, senior managers | The client |
| Focus | Current position, risks, decisions | Work completed over time, often with measures | Results, next steps, requests |
| How often | Weekly is common | Often monthly or at milestones | Weekly during active work |
| Tone | Factual, internal terms allowed | Formal, often longer | Plain, no internal terms |
In practice, many teams use "status report" and "progress report" for the same document. A simple way to tell them apart: a status report looks at now and next, and a progress report looks back over a longer period.
A client update is the client-facing version. It uses the same facts as your status report, but it leaves out internal detail like ticket numbers and staffing. It explains each item by what it means for the client.
How often should you send a status report?
Weekly is the most common schedule for active projects, and it is a good default. A week is long enough for real change and short enough that problems don't go unnoticed for long.
Adjust from there:
- More often during a launch or before a fixed deadline, when decisions can't wait a week.
- Less often, every two weeks or monthly, for long projects that move slowly or for senior readers who only need a summary.
Whatever you choose, send it on the same day each time so readers know when to expect it. Send urgent news, like a missed deadline, as soon as you know. Don't hold it for the next report.
How to write a status report
- Pick the reader. Write for one kind of reader. Decide what they need to know or do.
- Gather the facts. Check the plan, the task list and any open questions. Note what finished and what slipped.
- Decide the overall status. On track, at risk or off track. Be honest. A report marked on track for weeks that then announces a late launch makes readers doubt every later report.
- Write the decisions and risks first. These matter most to the reader. Put them where they will be seen.
- Summarize what's done and what's next. Write results, not activity, and include dates.
- Cut and check. Remove anything the reader won't use. Check names, dates and links.
To save time, start from the weekly status report template or the project status update template. You can also fill in a few fields in the free weekly status report generator and edit the result.
Status report examples
The three examples below use a made-up project: a small team rebuilding a client's website, including a new booking form. All names and dates are examples.
Example 1: a weekly project status report for the team
Website refresh: status report, week of 1 June
Overall status: At risk. The booking form is on schedule, but the team photos are late and the About page needs them.
Done this week
- Home and Services pages built and reviewed by Sam.
- Booking form connected to the calendar. Testing started.
Next week
- Finish booking form testing (Priya, by 10 June).
- Build Contact and FAQ pages (Sam, by 12 June).
Risks and issues
- The photographer moved the team shoot to 17 June. If photos arrive after 19 June, the 26 June launch moves by at least a week. Dana (client) is asking the photographer about an earlier slot.
Decisions needed
- Dana: approve the homepage layout by 5 June so Sam can finish the mobile version.
Changes since last report
- Newsletter signup moved out of this phase, agreed with Dana on 2 June.
Example 2: the same week as a client update
Hi Dana,
Done: The Home and Services pages are built, and the booking form now connects to your calendar. We're testing it this week.
Next: We'll finish testing the booking form by 10 June and build the Contact and FAQ pages by 12 June.
Needed from you: Please approve the homepage layout by 5 June. The mobile version is waiting on it.
One risk: The team photo shoot moved to 17 June. If the photos arrive after 19 June, the 26 June launch will move by about a week. Could you ask the photographer about an earlier date? I'll confirm the launch date in next week's update.
Look at what changed. The client version drops task owners and internal detail. It explains the risk by its effect on the launch date. The request has its own line and a date.
Example 3: a status report when nothing finished
Some weeks, nothing reaches "done". Send the report anyway. Say what is in progress, why it isn't finished, and when it will be.
Website refresh: status report, week of 8 June
Overall status: On track. No items finished this week.
In progress: Booking form testing. We found that bookings made after 11pm were saved to the wrong day. The fix is written and being tested now.
Next: Finish testing by 15 June. The 26 June launch date is unchanged.
Decisions needed: None this week.
A short, honest report is better than skipping a week. When a report doesn't arrive, readers start to wonder what went wrong.
Should you send your internal status report to a client?
Usually not as it is. An internal status report is written for people who know your process, task names and shorthand. A client who reads "QA blocked on vendor SDK" has to guess what it means for them.
Write a client version from the same facts instead. Keep every risk and date that affects the client. Remove ticket numbers, internal owners and tool names. Explain each item by what it changes for the client. The weekly client update guide shows how to write that shorter version.
Common mistakes in status reports
- Listing activity instead of results. "Had three meetings" tells the reader nothing. "Homepage layout approved" does.
- Putting the request at the bottom. Put decisions needed near the top, with a name and a date.
- Marking everything on track. If the project is at risk, say so early, while there is still time to act.
- Using numbers you can't support. Don't give a percentage complete unless you can say what it is a percentage of.
- Changing the format every week. Keep the same sections so readers know where to look.
FAQ
What is a status report used for?
To tell readers where a project stands and whether they need to act. It should make risks and decisions easy to find.
How long should a status report be?
Short enough to read in a few minutes. For most small projects, one screen or one page is enough. If yours is longer, check whether you are listing activity rather than results.
What is a project status report?
It's a status report for a single project. It covers one period, compares actual progress with the plan, and lists the risks and decisions for that project.
Who writes the status report?
Usually the person who runs the project. That might be a project manager, a team lead or the freelancer doing the work.
Conclusion
So, what is a status report? It's a short, regular summary of where a project stands: what's done, what's next, what's at risk and what's needed. Write it for one reader, put decisions and risks where they will be seen, and send it on the same day each period. When the reader is a client, write a plainer client update from the same facts.
If you send weekly updates to clients, Friday gives you a simple way to do it. You write one short update per project each week: what got done, what comes next, and what you need from the client and by when. The client gets the full update by email, with a link to a private page that keeps every update and reply. Start with the free weekly status report generator, or try Friday free for 30 days.