Project status report example: a template that drives decisions

Most status reports fail at the same thing: they prove the team was busy instead of telling the reader what to do. A good project status report answers one question for the person reading it, "is this project still on track, and is there a decision you need from me?" If a line in your report does not move someone toward a decision, surface a risk, or confirm the plan still holds, cut it. That is the whole argument, and the example below is built around it.

This page gives you a real, copy-pasteable project status report, a one-line RAG version for fast updates, and clear rules for which format to use when. Paste the template into an email, a Notion doc, or Slack and fill it in. The order of the sections is deliberate: status first, then what changed, then what you need. Stakeholders read top-down and stop early, so the most important thing goes first.

What a status report is for (and what it is not)

A status report serves people who are not in the weeds with you: a sponsor, a client, a steering committee, your manager. They do not want a diary. They want to know whether to keep their hands off the wheel or grab it. Everything else is noise.

That means three things people stuff into status reports do not belong there:

• A play-by-play of every task touched this week. That is what your project board is for.
• Justification of effort ("the team worked hard on..."). Effort is not status; outcomes are.
• Buried risks. If a risk needs a decision, it goes near the top, not in paragraph nine.

A project status report example you can copy

Here is the full template. It works for a weekly internal update or a client-facing report. Keep it to one screen. If it spills past that, you are reporting activity, not status.

PROJECT STATUS REPORT

Project:        [Project name]
Report date:    [YYYY-MM-DD]
Reporting period: [Start] to [End]
Prepared by:    [Name / role]
Overall status: GREEN | AMBER | RED

SUMMARY (2-3 sentences)
[Where the project stands and the single most important thing the
reader should know. If status is not green, say why in the first line.]

DECISIONS NEEDED FROM YOU
- [Decision]: [Options A / B] (needed by [date], because [impact of delay])
- [None this period]

PROGRESS THIS PERIOD
- [Milestone or deliverable completed]
- [Milestone moved from X% to Y%]

PLANNED NEXT PERIOD
- [What will be done by the next report]

RISKS AND ISSUES
- [Risk]: [Likelihood / impact] -> [Mitigation, owner, by when]

MILESTONES
| Milestone        | Due        | Status            |
| ---------------- | ---------- | ----------------- |
| [Name]           | [Date]     | On track / At risk / Done |

BUDGET (if tracked)
- Spent: [amount] of [budget] ([percent]). Forecast at completion: [amount].

Two things make or break this template. First, "Decisions needed from you" sits second, right under the summary, because it is the part with a deadline attached. A buried decision is a missed decision. Second, the RAG status at the top is not a vibe; it should map to defined criteria (see below), so the same situation gets the same color from any reporter.

A worked example, filled in

Abstract templates are easy to nod at and hard to copy. Here is the same template filled in for a fictional website redesign, so you can see the difference between reporting outcomes and reporting activity.

PROJECT STATUS REPORT

Project:        Acme.com redesign
Report date:    2026-06-12
Reporting period: 2026-06-06 to 2026-06-12
Prepared by:    Jordan Lee, Project Lead
Overall status: AMBER

SUMMARY
Design is approved and front-end build is underway, but the content
team is two weeks behind on page copy, which now threatens the
July 15 launch. We can hold the date if we get a decision on cutting
the blog migration from v1.

DECISIONS NEEDED FROM YOU
- Scope: cut blog migration from launch (move to phase 2) or push
  launch to July 29? Needed by June 17, because dev allocates the
  back half of June this Friday.

PROGRESS THIS PERIOD
- Final designs approved by stakeholders (June 9)
- Homepage and pricing page front-end built (was 0%, now 60%)
- Staging environment live

PLANNED NEXT PERIOD
- Build product and contact pages
- First QA pass on completed pages

RISKS AND ISSUES
- Content delay: high likelihood, high impact -> escalated to content
  lead; interim copy from marketing as fallback, owner Sam, by June 18.

MILESTONES
| Milestone          | Due        | Status   |
| ------------------ | ---------- | -------- |
| Design sign-off    | 2026-06-09 | Done     |
| Front-end build    | 2026-06-27 | At risk  |
| Launch             | 2026-07-15 | At risk  |

BUDGET
- Spent: $42k of $60k (70%). Forecast at completion: $61k (over by $1k).

Notice what this does. A reader gets the bad news (amber, content is late) in the first sentence, the exact decision and deadline second, and only then the supporting detail. They can act in thirty seconds. That is the test. For the upstream work of writing tasks that turn into a clean progress list, see action item tracking and the action items template.

RAG status: make the color mean something

RAG (red, amber, green) is the standard traffic-light system for project health, and it is the single most useful line in your report. Red means serious issues that need intervention now. Amber means at risk, with problems you are actively managing. Green means on track, no major concerns. The trouble is that "amber" means different things to different people, so the same project gets rated green by an optimist and red by a worrier (projectmanager.com).

The fix is to define the thresholds before the project starts and write them down. Then anyone reporting uses the same rule.

1. 1

   Green: on track

   Within tolerance on scope, schedule, and budget. No decision needed from sponsors. Risks are logged and under control.

2. 2

   Amber: at risk

   One or more of scope, schedule, or budget is slipping but recoverable with the plan you describe. You may need a decision.

3. 3

   Red: off track

   A key milestone, the budget, or the scope will be missed without intervention. Always pair red with a specific ask.

4. 4

   Write it down

   Put numeric tolerances next to each color (for example, amber = schedule slip of 1-2 weeks, red = over 2 weeks). Now color is consistent across reporters.

Which format to use when

The template above is a written report, and it is the right default for most teams. But "status report" covers a few different artifacts, and they are not interchangeable. Pick by audience and project type, not by habit.

Written status report

• Best for: sponsors, clients, weekly stakeholder updates
• Reads top-down, archives well, works async in email or Slack
• Carries decisions and risks better than any chart
• Use the template on this page

Dashboard or board view

• Best for: the delivery team and live standups
• Kanban, Gantt, or burndown shows flow and timing at a glance
• Great for execution, weak for surfacing the one decision you need
• Pairs with, does not replace, the written report

A few rules of thumb:

• Executive audience, async: written report, RAG at the top, one screen.
• Agile delivery team: a burndown or board is your living status; write the report for people outside the sprint.
• Budget-heavy or fixed-bid work: add a real budget line with forecast-at-completion, not just spent-to-date. Spend without a forecast hides overruns.
• Agency and client work: lead with outcomes the client cares about and keep internal process out of it. More on that cadence in client communication best practices and how to manage client expectations.

If you are juggling several of these at once, the reporting rhythm matters more than the format. See how to manage multiple projects for keeping cadence without drowning in updates, and template for project summary for the one-off wrap-up version.

Cadence: how often, and where the content comes from

Weekly is the default for active projects, biweekly for slow-burn ones, and a same-day flash report whenever status flips to red. The point of a cadence is predictability: stakeholders should know a report is coming so they stop pinging you for ad-hoc updates.

The hard part is not the format, it is sourcing the content without spending an hour a week assembling it. Most of a status report is already sitting in two places: your project tracker (for progress and milestones) and your meetings (for decisions, risks, and the asks that come out of discussion). The decisions and risks section is the one people fudge, because it lives in conversation and rarely gets written down in the moment.

This is where meeting notes do real work. If your weekly sync is recorded and summarized, the decisions, owners, and open questions are captured as they happen, and your status report becomes a copy-and-trim job instead of a recall exercise. A browser-based notetaker like Scribbl records and summarizes Google Meet calls with no bot joining the room, so the action items and decisions from your standup are already structured by the time you sit down to write. Pull the decisions into "decisions needed," the owned tasks into "progress" and "planned next," and you have most of the report before you type a word. For the meeting side of this, see how to take better meeting notes and summarize a meeting.

Common mistakes that make reports get ignored

• Reporting activity, not status. "Held three meetings and updated the deck" tells the reader nothing about whether you will hit the date.
• No ask. A report with no decision and no risk is a newsletter. If everything is genuinely green, say so in one line and stop.
• Color with no criteria. Undefined RAG drifts into watermelon territory. Define thresholds once.
• Too long. If the report is longer than one screen, you have buried the lede. Detail goes in appendices or the linked board.
• Late or irregular. A predictable mediocre report beats a brilliant one that shows up whenever. Set the cadence and hold it.

Frequently asked questions

What should a project status report include?

At minimum: an overall RAG health rating, a two-to-three sentence summary, any decisions you need from the reader (with deadlines), progress this period, what is planned next, and current risks. Add a milestone table and a budget line if the project tracks them. Keep the whole thing to one screen and lead with status and asks, not a list of tasks.

How often should I send a project status report?

Weekly is the standard cadence for active projects, biweekly for slower ones. The non-negotiable rule is predictability: send on the same day every period so stakeholders stop asking for one-off updates. On top of the regular cadence, send an immediate flash report any time status flips to red, since that is exactly the moment people need to act.

What do red, amber, and green mean in a status report?

Green means on track with no major concerns. Amber means at risk but recoverable with the plan you describe. Red means a milestone, budget, or scope target will be missed without intervention (projectmanager.com). The colors only work if you define numeric thresholds up front (for example, amber equals a one-to-two week slip), so the same situation gets the same color from any reporter.

How long should a status report be?

One screen. If a reader has to scroll twice, the important parts are buried. Lead with the RAG status and the decisions you need, keep progress to bullet points about outcomes, and push supporting detail into a linked board or an appendix. A status report is a signal, not a archive.

How is a status report different from a project summary?

A status report is a recurring snapshot of an in-flight project: where it stands right now and what you need this week. A project summary is usually a one-time wrap-up or overview, often written at the start or close of a project. Use the template on this page for the recurring update, and see template for project summary for the standalone version.