Project Status Report Template (Free, With Example)

A status report can take two hours to write and get read for ten seconds. Another can take fifteen minutes and get a decision from the sponsor before lunch. The difference has nothing to do with how much you write. It's about what goes first, and what gets left out.

This guide gives you a project status report template you can copy, a filled in example, and the habits that make a report worth reading. Our goal is a report that executives can take in within two minutes.

What is a project status report?

A project status report is a regular summary of where a project stands. It tells stakeholders whether the project is on track, what's been achieved, what's next, and what could derail it. Most teams send one weekly or every two weeks.

The audience matters. Executives want the headline and any decisions they need to make. The delivery team wants detail. Don't try to serve both in one document. Write the one page version for leaders and keep the details in your project tool.

What to include

Overall status

A single color at the top, with one sentence of explanation. Green means on track, amber means at risk but recoverable, and red means off track and needs help. Define what each color means for your project, so the colors aren't arguments.

Summary

Two or three sentences in plain words. If the reader stopped here, they'd still know the story.

Progress since the last report

The main things completed, linked to milestones or deliverables. Results, not activity.

Plan for the next period

What will happen next and who's responsible.

Milestones

A small table with planned dates, forecast dates and status.

Risks and issues

The top three to five, with what you're doing about each. If you keep a full risk list elsewhere, our free risk register template is a good way to set one up.

Decisions and help needed

The part executives actually act on. Say exactly what you need and by when.

Budget and effort

Spend to date against plan, in a line or two.

A free project status report template

A filled in example

Here's an illustration for a customer portal project, reporting on the week ending Friday 6 November.

Read that in a minute and you know where things stand, what the problem is and what to do about it. That's the whole job.

How to define red, amber and green

Colors only help if everyone reads them the same way. Write your definitions down and share them at the start of the project. Here's one simple set.

Agree the thresholds too. For example, amber if a milestone slips by up to a week, red if it slips by more than that. Numbers settle disputes before they start.

Different readers, different versions

For executives

The one page report. Headline, status color, top risks, decisions needed. Nothing else.

For the project team

More detail on tasks, blockers and next steps, usually straight from the board or task list.

For clients

Focus on deliverables and dates, and be careful with internal details like team capacity or disagreements. Keep it honest, but keep it relevant.

You can build all three from the same data. Write the detailed version first, then trim it down for each audience.

A simple routine for writing it fast

• Update your task statuses before you start, so the data is current

• Copy last week's report and change what changed

• Write the summary last, when you know the story

• Read it once as if you were the sponsor, and cut anything that doesn't help them decide

• Send it at the same time every week

With a routine like that, a good report takes fifteen to twenty minutes. The first few will take longer, and that's fine.

How to make it quick to read

• Put the status color and the headline first

• Use plain words, with no jargon the sponsor would need to translate

• Keep bullets short, ten words or fewer where possible

• Put decisions in their own section, not buried in a paragraph

• Stick to the same layout every time, so people know where to look

Pulling the numbers without hours of work

The slowest part of a status report is usually collecting the data. If your tasks, time and progress live in one tool, you can copy numbers straight from there. Progress inside a sprint is easy to show with a chart, and our burndown chart guide explains what to read from it.

For effort and spend, accurate logs matter. The reporting and effort logs in Sanplex make it easier to see where time went, so your budget line isn't a guess.

A word on tools

Whether you use a document, a slide or a dashboard matters less than consistency. Pick one format, keep it in one place and make sure the numbers come from the same source every time.

Keep an archive

Store every report in one folder or page, in date order. When someone asks what you reported in September, you can answer in ten seconds. The archive is also a quick way to see how a project's story unfolded when you write the closing report.

Ask for feedback

Every couple of months, ask two or three readers what they'd change. People are usually happy to say which sections they skip, and cutting those makes the report better for everyone.

How often to send it

Weekly for fast moving projects, every two weeks for steadier ones, monthly for long programs. The right rhythm is the one people will read. If nobody opens your weekly report, try sending a shorter one less often.

What to leave out

Knowing what to cut matters as much as knowing what to include. Leave out routine tasks nobody needs to know about, long lists of meetings held, technical details that only the team will understand and anything you wouldn't be able to explain in one sentence.

If you're not sure whether to include something, ask whether the reader would do anything differently after reading it. If the answer is no, it belongs in the detailed project plan, not in the report.

Trend over snapshot

Add a small note showing the status last time, such as "amber, was green." A snapshot tells readers where you are. A trend tells them where you're heading, and that's often what they really want to know.

Handling a report with bad news

Put the bad news first, in plain words, and follow it straight away with what you're doing about it and what you need. "The API delay puts the beta date at risk. We've escalated and need Engineering to prioritize by Wednesday." That's honest, calm and gives the sponsor something to do. Burying bad news in the middle of a long page is what damages trust.

Honest reporting beats green reports

There's a temptation to keep the status green until it suddenly isn't. Resist it. A project that goes from green to red in one week frightens people. A project that goes amber early, with a plan, builds trust. Stakeholders forgive bad news. They don't forgive surprises.

Mistakes to avoid

Writing an essay

If it needs scrolling, it's too long. Move the detail to a linked page.

Reporting activity instead of results

"Held six meetings" tells nobody anything. "Agreed scope with finance" does.

Hiding the ask

If you need a decision, say so in the first half of the page.

Changing the format every week

Consistency lets readers spot changes at a glance.

Frequently asked questions

What is a project status report?

A regular summary of a project's progress, current status, risks and next steps, written for stakeholders and sponsors.

What should a project status report include?

Overall status, a short summary, progress made, plans for the next period, milestones, key risks and issues, decisions needed, and budget or effort to date.

How long should a project status report be?

One page. Executives should be able to read it in about two minutes, with detailed information linked elsewhere.

What does RAG status mean?

RAG stands for red, amber and green. Green means on track, amber means at risk but recoverable, and red means off track and in need of help or a decision.

How often should I send a status report?

Weekly or every two weeks for most projects. Choose a rhythm that matches the pace of the project and what stakeholders will actually read.